Patrick Elliott wrote:
> 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. 

You could also assume that a render command is implicit at the end of 
parsing if none is given.


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.
>

Post a reply to this message