Re: Frame System

--===============1775561873==
Content-Type: multipart/alternative; 
	boundary="----=_Part_103317_26834349.1159949513633"

------=_Part_103317_26834349.1159949513633
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

---
No, you still don't understand me. I don't talk about the povray code
itself, but about the generation of the povray code. The povray code is
fine, I have only problems how to generate that.
---
I did understand you, and i know that it was going to be a pain in the back
to code it
and check check check, and i thought it was worth the pain for the result o=
f
avoiding bottleneck in clusters, hehehe but that stuff is stuff i've work i=
n
the institute, and outside Kpovmodeller.
But eventually it will have to be like that.
But seems that i jump some steps like
1.- there is no frames system yet
2.- there is not a 100% stable cluster support in KPM
3.- worrying about cluter bottleneck, when not having the cluster and the
cluster support and the animation system.

(i feel weird, i feel like i owned myself with that comment)


---
And with your idea you have to check for every property in every object
whether a variable name or the actual value should be exported which is
IMHO quite ugly.
---
Lol, ugly sounds like bad coding, lets say its quite "barbaric" or "rude"
but
its the optimal solution if we want to export to POVRay (as 1or 2 if
separating the animation file as an include).

Thinking about a previous comment that KPM is KPM with some renderer (POVRa=
y
renderer in this case)
If we forget the POVRay exportation, (which i still think its VERY
important, and this may be because, i've worked much with POVRay code and
its renderer (i've actually touched POVRay renderer code)) then well the
Andreas idea would be the very best (far best) for this case. but it would
inhibit (or make it very very very hard) to implement exportation to povray
code), and well in this case, there is a KPM file format "who cares about
.pov?"
(not sarcastic nor cynical, i meant it as it looks like)

I've already started working a little with this, and i hope (i almost
promise) that within 2 weeks i'll have something working.

Perhaps this weekend but cant be sure.
:D  :D :D

Have a nice day everyone.

Miguel =C1. G=F3mez

------=_Part_103317_26834349.1159949513633
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

---<br>No, you still don't understand me. I don't talk about the povray cod=
e<br>itself, but about the generation of the povray code. The povray code i=
s<br>fine, I have only problems how to generate that.<br>---<br>I did under=
stand you, and i know that it was going to be a pain in the back to code it=
=20
<br>and check check check, and i thought it was worth the pain for the resu=
lt of avoiding bottleneck in clusters, hehehe but that stuff is stuff i've =
work in the institute, and outside Kpovmodeller.<br>But eventually it will =
have to be like that.
<br>But seems that i jump some steps like<br>1.- there is no frames system =
yet<br>2.- there is not a 100% stable cluster support in KPM<br>3.- worryin=
g about cluter bottleneck, when not having the cluster and the cluster supp=
ort and the animation system.
<br><br>(i feel weird, i feel like i owned myself with that comment)<br><br=
><br>---<br>And with your idea you have to check for every property in ever=
y object<br>whether a variable name or the actual value should be exported =
which is
<br>IMHO quite ugly.<br>---<br>Lol, ugly sounds like bad coding, lets say i=
ts quite &quot;barbaric&quot; or &quot;rude&quot; but<br>its the optimal so=
lution if we want to export to POVRay (as 1or 2 if separating the animation=
 file as an include).
<br><br>Thinking about a previous comment that KPM is KPM with some rendere=
r (POVRay renderer in this case)<br>If we forget the POVRay exportation, (w=
hich i still think its VERY important, and this may be because, i've worked=
 much with POVRay code and its renderer (i've actually touched POVRay rende=
rer code)) then well the Andreas idea would be the very best (far best) for=
 this case. but it would inhibit (or make it very very very hard) to implem=
ent exportation to povray code), and well in this case, there is a KPM file=
 format &quot;who cares about .pov?&quot;=20
<br>(not sarcastic nor cynical, i meant it as it looks like)<br><br>I've al=
ready started working a little with this, and i hope (i almost promise) tha=
t within 2 weeks i'll have something working.<br><br>Perhaps this weekend b=
ut cant be sure.
<br>:D&nbsp; :D :D<br><br>Have a nice day everyone.<br><br>Miguel =C1. G=F3=
mez<br>

------=_Part_103317_26834349.1159949513633--

--===============1775561873==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


List archive and information: https://mail.kde.org/mailman/listinfo/kpovmodeler-devel
--===============1775561873==--