'Re: Frame System'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kpovmodeler-devel
Subject: Re: Frame System
From: "=?ISO-8859-1?Q?Miguel_Angel_G=F3mez_M=E1rquez?=" <atomicmx () gmail ! com>
Date: 2006-10-03 17:20:47
Message-ID: c49bcf870610031020r7ccd44b2oc0fbedc7ee56f9c5 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

I  definetly agree, they hardly fit, because Kpov wasn't originaly supposed
to render
animations, in the other hand, they can be implemented quickly with a
"little drawback" as kpov file, but i ask again, how do you plan to export
an animation to povray code? exporting 1200 povfiles maybe? or povray code
exportation for animation would be nullified.

Doing they way i hipoteticaly propose, would let to export an animation
directly to 1 single povray file.
I may be wrong (because i haven't started coding yet)
But i belive it would worth the try.
Give me 2 weeks, and i'll have you (all) ready a "very rough" example of my
idea.

----
What I had in mind is to loosely connect the animation objects or scripts
with the animated objects, what means that the objects have no idea that
they are animated.
-----
And whats the difference with what i posted? (its a real question, lol)
The animation would be in an include file, which if not being present, would
draw the first frame. the objects don't know of the animation.

---
Following your idea, an object A has to know that property B is modified by
the animation system and should be exported to povray not with the actual
value but with a constant and it has to know the name of that constant.
Every single object and every single attribute. Just think about how to
implement that without modifying every object, and implementing that in a
plugin is not possible at all.
If you bring up a good solution here you can convince me :-p
---
Ammm this is solved as easy as using the objectname (for the varnames ) and
a property counter.

-----
It is a little drawback that with my system every frame has to beexported as
separate povray file, but IMHO that's really only a little drawback. The
main bottleneck is rendering of the scene, not the IO or disc space.
----
The problem for example when using POVRay in parallel the bottleneck is the
reading of the file all cluster jobs depends on and this is a known issue
presented (found) by the developer of MPI POVRay.
This is why i give it so much importance.
It is not a drawback at all in domestic use.

---
The main advantage is that animation with scripting or other method
thatmodify objects with the existing property system is that no single
lineof code has to be changed in individual objects.
---
Annnnnnnnnd this is why it hardly fits.

Hmmm...
I'd like some opinions, this looks more like a debate than a mailing list
(forum).
If we implement it as Andreas says, the animation system would be running
(unstable) in a month at most, because it is really easy to implement it
that way.

[Attachment #5 (text/html)]

<div><div>I&nbsp; definetly agree, they hardly fit, because Kpov wasn't originaly \
supposed to render animations, in the other hand, they can be implemented quickly \
with a &quot;little drawback&quot; as kpov file, but i ask again, how do you plan to \
export an animation to povray code? exporting 1200 povfiles maybe? or povray code \
exportation for animation would be nullified. Doing they way i hipoteticaly \
propose, would let to export an animation directly to 1 single povray file. I may \
be wrong (because i haven't started coding yet) But i belive it would worth the \
try. Give me 2 weeks, and i'll have you (all) ready a &quot;very rough&quot; \
example of my idea. </div><div> ----&nbsp;</div>What I had in mind is to \
loosely connect the animation objects or scripts with the animated objects, what \
means that the objects have no idea that they are animated. ----- And whats the \
difference with what i posted? (its a real question, lol) The animation would be \
in an include file, which if not being present, would draw the first frame. the \
objects don't know of the animation. --- Following your idea, an object A \
has to know that property B is modified by the animation system and should be \
exported to povray not with the actual value but with a constant and it has to know \
the name of that constant.&nbsp; Every single object and every single attribute. Just \
think about how to implement that without modifying every object, and implementing \
that in a plugin is not possible at all. If you bring up a good solution here \
you can convince me :-p --- Ammm this is solved as easy as using the objectname \
(for the varnames ) and a property counter. ----- It is a little drawback \
that with my system every frame has to beexported as separate povray file, but IMHO \
that's really only a little drawback. The main bottleneck is rendering of the scene, \
not the IO or disc space. ---- The problem for example when using POVRay in \
parallel the bottleneck is the reading of the file all cluster jobs depends on and \
this is a known issue presented (found) by the developer of MPI POVRay. This is \
why i give it so much importance. It is not a drawback at all in domestic \
use. --- The main advantage is that animation with scripting or other \
method thatmodify objects with the existing property system is that no single lineof \
code has to be changed in individual objects.&nbsp; --- Annnnnnnnnd this is \
why it hardly fits. Hmmm... I'd like some opinions, this looks more like a \
debate than a mailing list (forum). If we implement it as Andreas says, the \
animation system would be running (unstable) in a month at most, because it is really \
easy to implement it that way. </div>

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

[prev in list] [next in list] [prev in thread] [next in thread] 