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 th
e 
> > 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 matric
es
> afterwards. It's simply a question of which transformations are applied t
o
> 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 transforma
tion
> is simply a command (a kind of "function call" if you like) which modifie
s
> 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.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message