Patrick Elliott wrote:
> In article <4709fb43@news.povray.org>, war### [at] tagpovrayorg says...
>> Patrick Elliott <sel### [at] rraznet> wrote:
>>> If you have something like:
>>> #declare yy = clock
>>> sphere {...
>>>   translate <yy,35,61>
>>>   texture { some_complex_texture translate 100*x}
>>>   translate y*2}
>>> Then you **must** reparse the object every single time, because once the 
>>> object exists internally, it can't be changed.
>>   Wrong.
>>
>>   The object has its own transformation matrix and the texture its own.
>> All transformations applied to the object go to its transformation matrix,
>> and all transformations applied to the texture (be it directly in the
>> texture block or indirectly in the object block) go to the transformation
>> matrix of the texture.
>>   It would be perfectly possible to alter these two transformation matrices
>> afterwards. It's simply a question of which transformations are applied to
>> the object only, which ones to the texture only and which ones to both.
>>
>>> The 
>>> transforms you need to be able to change are "not" sitting conveniently 
>>> as the last thing in the object, they are buried deep within the 
>>> structure.
>>   You seem to have this concept that the transformations are somehow
>> stored in the definition of the object, and that this order must be
>> preserved.
>>
>>   The individual transformations are not stored anywhere. Each transformation
>> is simply a command (a kind of "function call" if you like) which modifies
>> the internal transformation matrix of the object.
>>
>>   It would be perfectly possible, after the object has been created (with
>> the transformations and all), to reset its transformation matrix and then
>> apply the same transformations to it, resulting in the exact same end
>> result. The only distinction you have to make is which transformations
>> go to the object, which ones to the texture and which ones to both.
>>
>>> If we want to be able to animate, without a reparse, we need 
>>> an internal representation that allows "each" transform, texture, 
>>> object, etc. to exist as accessible elements, not as static 
>>> declarations.
>>   No we don't.
>>
>>> In other words, you need to make it "look" like:
>>> yy = yy + 1
>>> mysphere.translate(0)=yy,35,61
>>> Even as the engine keeps track of "how" those things connect:
>>> start->translate(0)->texture(0)->translate(1)->end
>>   The engine doesn't need to keep track of that. You should acquaint
>> yourself with transformation matrices and how they work.
>>
>>> How else do you both allow animation, without a reparse, but also 
>>> maintain the capacity to place as many transforms, or other elements, 
>>> into the object as you can now?
>>   You can write a thousands individual transformations into an object,
>> yet none of them will be (individually) stored anywhere. They are all
>> applied to one single 4x4 transformation matrix. POV-Ray doesn't need
>> to keep track of the individual transformations nor store them anywhere.
>>
>>   The only thing you need to specify is whether a certain transformation
>> is applied to the object, to the texture, or both.
>>
>>> See what I am getting at? If you want to maintain the "existing" SDL, 
>>> you have to allow for this, or suffer the current consequence of having 
>>> to reparse the "entire" SDL every frame.
>>   That's just not true. The only thing you have to allow in the new SDL
>> is to be able to apply transformations to the object only, the texture
>> only or both at the same time. This is very trivial to do.
>>   It's perfectly possible to transform the object but not the texture
>> even after the texture has been specified.
>>
>>
> Sigh.. You are I think making an assumption that, when you do want to 
> change something, you would only want to change "one" transform. But, 
> maybe you have a dozen, each with does something specific to positioning 
> the object, each of which is "also" effected by all of the prior 
> transforms. Tell me, with a real example, not just some assertion that I 
> am imagining a problem, how you do that. Yes, you can use some commands 
> that can revert the object to a known state, like at the origin, then 
> transform it, but that is useless if the transform you need is relative 
> to some arbitrary point, which is the result of 3-4 other prior 
> transforms. How do you, if you are doing say 7 translates, for some odd 
> reason, revert back to the 3rd, change the 4th, then reapply the last 3? 
> You can't, without drastically altering how you handled those transforms 
> in the first place, and reducing them to a bare minimum number needed to 
> do the task. Sure, it might be possible, but it still breaks, as near as 
> I can tell, when you try to provide a post-creation transform on the 
> object, to modify the prior result. Show me that I am wrong, don't just 
> tell me I am.
> 
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'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.

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

Post a reply to this message