POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
13 Jul 2025 11:11:34 EDT (-0400)
  Re: New SDL for POVRay  
From: andrel
Date: 9 Oct 2007 16:43:11
Message: <470BE8E1.80902@hotmail.com>
Bruno Cabasson wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Bruno Cabasson wrote:
>>> andrel <a_l### [at] hotmailcom> wrote:
>>>> Bruno Cabasson wrote:
>>>>> Concerning the animation problem, I see things as follows:
>>>>>
>>>>> Solution 1:
>>>>> -----------
>>>>> The nth frame I(n) of an animation is a function of time only. Its
>>>>> description depends on the sole time parameter. Then you can conceptually
>>>>> write:
>>>>>
>>>>> I(n) = F(tn), with F being the function that describes the scene at time tn.
>>>>>
>>>>> This is POV's point of view, through the 'clock' variable and reparsing the
>>>>> whole scene (except radiosity and photon maps if so specified).
>>>>>
>>>>> This solution requires only the description of the F(t) function.
>>>>>
>>>>> Solution 2:
>>>>> -----------
>>>>> The nth frame I(n) is made by delta wrt first frame. Its description relies
>>>>> on the description of first frame at t0 and a delta function that depends
>>>>> on the time parameter. Then you can conceptually write:
>>>>>
>>>>> I(n) = I(0) + D(tn), with D being the function that describes the variation
>>>>> of the scene between tn and t0.
>>>>>
>>>>> This solution requires the decription of I(0) and the D(t) function.
>>>>>
>>>>> Solution 3:
>>>>> -----------
>>>>> The nth frame I(n) is made by delta wrt previous frame. Its description
>>>>> relies on that of the previous frame I(n-1) and a delta function that
>>>>> depends on the two instants tn and tn-1. Then you can conceptually write:
>>>>>
>>>>> I(n) = G(I(n-1)) = I(n) + d(tn, tn-1), with d being the function that
>>>>> describes the variation of the scene between tn and tn-1.
>>>>>
>>>>> This solution requires the description of I(0) and d(t1, t2) function.
>>>>>
>>>>>
>>>>> Each of these solution is a different approach with pros and cons and
>>>>> implies related features and syntax.
>>>>>
>>>>> Concerning POV4, which of these is preferable?
>>>>>
>>>> none or all
>>> What do you mean exactly? I don't get your point ...
>> simply that if at frame n you want to position and transform an object
>> you will be allowed to access the state in frame n-1, so you can
>> transform incremental (3). You can also reset the transformation
>> variables and start from there (1) or first revert to a known situation
>> either because POV4 gets a mechanism to make a snapshot or because
>> somebody will write a function (formerly a #macro) to do so.
>>
>> So all will be possible and none will be preferable. It depends on the
>> application which one is more natural and if you use a GUI you won't
>> even know.
> 
> OK, but I'm still not sure I get you. You seem to suggest that POV4 should
> implement all 3 approaches for convenience reasons, and that they are
> equivalent wrt this. But would not implementing all 3 (or more) solutions
> yield too a voluminous syntax and wouldn't it be somewhat confusing to the
> user instead of being more convenient? And POV4 would have to implement
> all, which means more development effort.
no not at all, it would be more difficult to implement it in a way that 
only one option is possible.
Here is how is might be done:
scheme 1)
/* everything parsed, now in the segment that positions for frame FrameNr */
object.transform.reset // revert to initial position
object.translate(X(FrameNr),Y(FrameNr),Z(FrameNr))
object.rotate(A(FrameNr),B(FrameNr),C(FrameNr))

scheme 2)
/* everything parsed, now in the segment that positions for frame FrameNr */
/* keep current transform matrix */
object.translate(dX(FrameNr),dY(FrameNr),dZ(FrameNr))
object.rotate(dA(FrameNr),dB(FrameNr),dC(FrameNr))
/* note: rotate and translate do interact */

scheme 3)
/* at the end of the creation of the objects, but before the */
/* positioning of objects for frame FrameNr */
if FrameNr==0
   save_transforms_of_all_objects
else
   load_transforms_of_all_objects
/* everything is now positionable wrt to first frame */
   object.translate(X(FrameNr),Y(FrameNr),Z(FrameNr))
   object.rotate(A(FrameNr),B(FrameNr),C(FrameNr))
end

> 
> BTW, considering the problem of POV4's development: who will? What is the
> manpower and skills available today? We have POV-team and perhaps
> volunteers around here. But it is quite a long-term commitment. Would
> POV-team members be likeley to? Such a developmement requires a good
> implusion at the start AND perennial manpower AND a team developmement
> process. To my understanding (and whish), POV4 cannot be a hack. It
> requires an 'industrial' process, whether or not it is open-sourced.
> Anyway, I don't worry about the testing power ...
> 
>>> POV has currently solution 1.
>> no, it reparses the scene for every frame.
> 
> This is precisely what I(n) = F(tn) means: every frame is a function of the
> sole time parameter through the clock variable. Solution 1 means therfore
> that the scene is reparsed every frame, all stuff of the scene is re-build
> from scratch and from the clock variable or its derived variables such as
> frame_number. They all represent an 'absolute' time.
There is no need to reparse the object creation block in POV4.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.