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.

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.


Bruno

Post a reply to this message