In article <470### [at] hotmailcom>, a_l### [at] hotmailcom 
says...
> What I was saying is that we should distinguish between the 'first 
> creation' and the 'final creation'. Calling both simply 'creation' will
 
>   lead to confusion (as shown is this thread. Much of what you and 
> Patrck are writing does not make sense to me, because for me 'creation'
 
> is 'final creation').
> 
How about "intermediary" creations then, just to confuse things more. 
lol Technically, by your definition, the object is never "created" until 
the frame in rendered, at least in any system like we are talking about, 
where each "frame" is defined not by re-running the entire script, but 
only via the command "in" the script.

In other words, in the current model we do this:

render("myfile")

in a true animation system, we do this:

'Set up a bunch of objects.
...
render
'Change the objects some.
...
render
'Change them some more.
...
render

The "render" step is explicit in the script, since it only happens 
"when" all the changes are made, not an external process that just runs 
an SDL through it, and recalcs the data for everything as it does it, 
based on the existing clock scheme, which is kind of limited. Mind you, 
making that change, depending on how it was done, could break existing 
SDL. Mind you, a command that "requests" the prior behavior could be 
used to solve that. Note, allowing a "render" command to explicitly tell 
it when you are ready to render the result means you could simply do:

light {...}
camera {...}
plane {...}
object1 {...}
render
object2 {...}
render
...

And produce a frame by frame set of changes. Could be useful for 
debugging too. Not sure what is causing a problem, go through one object 
at a time, until you find a frame where the problem crops up.

Note: Obviously one thing you can do with this is make the "render" 
command do several things. If you haven't set any animation/clock 
parameters, then it generates the same name each time. If you have set 
them, it increments a frame count each time you use it, while also 
incrementing the clock by the predefined amount. Obviously, to limit the 
need for the definition files currently used, since you might want 
better control over things, you would want clock data 
accessable/changable via something like:

clock.state - on/off
clock.start_frame
clock.frame
clock.end_frame
clock.increment

Same possibly even with things like the render size, etc.

You could conceivably even allow "render" to also allow "render
(frame_number, fill)". I.e., if you want to freeze frame, instead of 
generating 10 identical frames you just change the "frame" you are on, 
then specific that everything between "last frame" and "current frame" 
gets filled with the last rendered image.

Mind you this could be done, in *some* software by just telling that to 
duplicated those frames, but not all of them will do that, and if at 
some point someone added a stream encoder to POVRay, being able to 
explicitly tell it that frames 5-15 are duplicates would speed up the 
process of both generating those frames "and" encoding them, the encoder 
could just be told, by the engine, to encode the same "frame" ten times, 
at the frame rate it was already given. No additional "data" need be 
produced.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message