Bruno Cabasson wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Patrick Elliott wrote:
>> I don't want interfere in your personal fight, but I think this is what
>> is going to happen:
>> - POV4 transformations will be implemented the same as in current POV,
>> one transformation matrix per object, texture.
>> - The language will be enhanced and the processing of it changed in such
>> a way that retransforming one or more specific elements will become an
>> issue. e.g. in generating the next frame of a complicated object without
>> reparsing the lot.
> 
> It is the Frame(n) = Frame(0) + Delta(tn) scheme, with Frame(0) representing
> most of the parsing (initial conditions of the scene, building of objects
> ....), and Delta(tn) the variation of the scene since first frame. The
> function Delta() can be expressed (and syntaxted) as timelines attached to
> objects, handled by a corresponding control process. These time lines would
> then embody the memory of the transformations to apply through time (the
> 'array' of transformations in question in the next paragraph)
> 
>> - it'll be up to the user to implement a stack of transformations if he
>> thinks he needs one. Reverting to a marked state and replaying the
>> changed set of transformations from that point.
>> - luckily the language will be enhanced in such a way that such an
>> implementation is easy.
> 
> I think that leaving the responsability to handle these stacks of
> transformations to the programmer is dangerous and requires too much
> programming skills wrt the goal we intend to reach in terms of programming
> ease and accessibility. In the scheme I described, only the control process
> of timelines can do the job and guarantees sensible operations.
> 
>> Also before fighting on, you should first define what you mean by
>> creation/post creation etc. I think you have a different view on when an
>> object is actually created. Is that e.g at the end of the union defining
>> it (Patrick?) or at the end of parsing (warp?).
>> If you assume the latter (which happens to be my point of view) post
>> creation transforms do not exist, by definition.
> 
> My point of view is that within a single frame, all transforms should be
> defined at creation time, and post creation transforms should be forbidden,
> unless controlled by the timelines attached to the objects and their control
> process within aniations (and in this sole case).
> 
> 
>> ... BTW I think the time of
>> definition of the shape also needs a name (birth? though you will be
>> able to clone after birth... conception?), because it is a significant
>> moment in the life of that object. I predict that it'll come up in
>> discussions about POV4 frequently.
> 
> As we try to make POV have some OO aspects, I'd rather be inclined to keep
> the term of 'creation'.
> 
My point is that there are more than one moment where an object is 
'created'. The first time when is is fully constructed for the first 
time at some arbitrary point with its transform matrix fully reset. The 
final time is when the rendering starts at that point is has reached its 
final position, orientation and scale. In between there may be moments 
that it is repositioned (etc.) and included in a larger object, so that 
from the perspective of that object it is fully created but the compound 
can still be transformed. It might even be technically possible that the 
implementation would allow to reposition an object from within a shader 
program, but I would be against that.

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

Post a reply to this message