Bruno Cabasson wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> I haven't seen any argument from you that does a thing to truly address
>>> that issue.
>>   That's because you have a misunderstanding about how transformations work.
>>
>>   Answer me this: Why the current POV-Ray doesn't need object-specific
>> transformation arrays?
>>   The answer is not "because it re-parses the objects at each frame".
>> That re-parsing could perfectly be skipped with the proper syntax changes.
>>
>> --
>>                                                           - Warp
> 
> Appart from this (somewhat sterile) passionate discussion, the problem of
> animation-specific features and releted syntax seems to be a major concern
> for POV4. I encourage other people here to search for ideas and make
> propositions. Patrick proposed something, Warp disagrees, and both argue.
> OK, fine.
> 
> Now, are there here experienced people that could give us some additional
> advise and share their knowledge to help us find our way? 

I tried to explain my views in my oct 9 22:47 post in this thread.
( 
http://news.povray.org/povray.general/message/%3C470BE8E1.80902%40hotmail.com%3E/#%3C470BE8E1.80902%40hotmail.com%3E

)
Not much needs to be added to the current implementation of the objects 
and how we define them. There is no need to break the definition of any 
existing SDL object.

For animation to be more simply handled it is enough if we get some 
access to subparts of an object and their current transformation matrix.
For this to work there must be a way to name subparts of an object, 
because we would like to say Human.LeftArm.ForeArm.rotate(<10,0,0>) That 
would mean that the SDL syntax has to be expanded slightly e.g. like

Human=union{
   Head=union{
     sphere{...}
     ...}
   }
   LeftArm=union{
     ...
   }
   RightArm=union{
     ...
   }
   ...
}

(unless the '=' would cause trouble during parsing, then ':' might do.)
If the (optional) name is left out it should default to a predictable 
name e.g. __Child[N] So, to get a bigger head we could write: 
Human.Head.__Child1.scale{1.5)

Possibly the base of the default name could even be name of the object, 
  resulting in Human.Head.sphere1.scale(1.5) and the right arm may be 
accessible as Human.union3, but I cannot see if that would screw up the 
parsing or not.

Post a reply to this message