In article <47083c29$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >> sphere.translate[0]="<5,0,0>"
> > 
> >> I think it's a bad idea to allow changing individual transformation 
> >> statements after the object has been created.
> > 
> >   There's no such a thing as a "translate" element in a sphere (or in
> > any other object for that matter). Thus it would make no sense to have
> > such an element in the sphere object of the new SDL either.
> > 
> >   What should exist is a *function* (member or not) which applies the
> > translation to the sphere (which is a different thing). Calling this
> > function will, naturally apply the subsequent translations properly
> > (as well as other transformations).
> > 
> >   (In general all transformations are internally collected into a
> > 4x4 transformation matrix, except when the transformation can be
> > optimized away by eg. transforming the center point of the sphere
> > only. However, there exists no "translate" member variable in the
> > sphere object or any other object.)
> > 
> 
> Yep, that was my point. Transforming the object further should *of 
> course* be allowed (complex CSG would become fairly impossible without 
> that!), but having all individual transformation "items" stored in an 
> array and being modifiable seems like a bad idea.
> 
> That was what Patrick Elliot said, and I was replying to:
>  > And you want to adjust the "first" rotation.
>  >
>  > body.arm.rotate(0)="<5,0,0>"
>  >
> 
Hmm. Ok. That case I hadn't considered. I was thinking in terms of ease 
of identifying the transformation, not in terms of how they interact. 
Its messier to do something like:

body.arm.transform(0)="<5,0,0>"

since you would **have to** know that the "first" transform was the 
rotate, not something else. Short of including, as part of the internal 
data, some concept as to the "order" of the overall operations, so that 
changing the transform would not effect order. Think of it kind of like 
dynamic parsing. Instead of recreating the object in every single frame 
of an animation, you create it once, then *only* adjust those textures, 
transforms, etc. that are *needed* to change, without having to restate 
it all in SDL. Now, you can't do that right now. 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. However, you *must* be 
able to change it, of you want it to do what its supposed to, because 
its *not* the final transform that is being effected, but the one that 
happens prior to the final change. This is especially true if dealing 
with something that has, for example, a complex IK chain system. 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. 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. 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

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? The only other way to do it is by 
forcing someone to "only" allow certain types of transforms, like 
"rotate", "rotate at object coordinate (such as one of its corners, or 
slightly off of center" and "rotate at origin". In other words, you 
either maintain an internal concept of which elements define the object 
and allow those to be changed "independently" by object references, 
**or** you limit the actual transforms to ones that specify distinct 
behaviors, and force someone to use only the one they need, instead of 
letting them make changes to the individual elements defined in the 
original object.

Mind you, there is "one" alternative. Reparse only the bits you need. 
I.e., what the user sees is:

sphere
  |-translate()
  | |-(0) translate blah
  | |-(1) translate blah
  |-texture()
    |-(0) texture data

What the engine sees is:

sphere
  |-translate blah
  |-texture
  | |-data for that
  |-translate blah

So, the next frame, it "reparses" the "engine" version, in its original 
order and associations, to get the new sphere for that frame.

This is sort of what you would have to do, no matter "how" you stored 
things internally, unless, as I said, you allowed "creation" of an 
object using the original SDL syntax, but then required the "script" 
portion to use the more limited set of "allowed" actions, as with the 
rotate example above.

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. If you avoid doing that, then 
you are still stuck either somehow selectively re-making, based on key 
changes, the internal representation, by basically reparsing it in some 
fashion anyway, or you have to limit what "is" allowed. You can't do 
what is needed with the SDL as it exists, without basically doing the 
same thing anyway, and if you are going to "store" those representations 
and the order they occur, there is no reason to not provide an means to 
look at or even change *what* is stored in those elements. The engine 
"still" has to figure out what those changes "mean" in the next frame, 
in terms of the final result of how the object is effected.

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