In article <470ced0a$1@news.povray.org>, ele### [at] netscapenet 
says...
> Patrick Elliott nous apporta ses lumieres en ce 2007/10/10 01:42:
> 
> > I think we are talking past each other here in some respects. Yeah, I
 
> > agree, if they work in the sense that they should, i.e., scaling 
> > "before" defining the last object in a union also scales "that" object,
 
> That's not a valid syntax and generate an error at the next object encoun
tered.
> You can transform any individual element.
> You can transform the whole CSG object, but ONLY after every last one of 
it's 
> elements have been included.
> > not just the prior ones, then applying all transforms "after" is 
> > perfectly valid. It doesn't fundamentally change my argument, which is
 
> > that, "If you are going to store that stuff in an array, lets at least
 
> > assign the array to something that "looks" like its part of the object,
 
> > and not some separate entity." In other words, if you are going to appl
y 
> > 10 transforms to object Z, then *make that array* part of the Z object,
 
> > *at least* from the perspective of the coder. That way you can tell 
> > "what" they belong to by simply referencing the object they belong to,
 
> > not some arbitrary array that has no association, save that you just 
> > happen to use it for that.
> > 
> > Or is there some huge objection to making it even than simplified?
> > 
> > Oh, and the idea of placing each "type" of transform into a separate 
> > array is more like a filter. I.e., you want to change the 3rd "scale",
 
> > just reference the 3rd scale in the array, even if it is "actually" the
 
> > 7th transform. This doesn't even need to be a separate array, just a 
> > function call that counts the transforms in the main array, until it 
> > gets the "nth" transform of the type requested. In other words, 
> > something like:
> > 
> > function translate(n)
> >   c = -1
> >   for each temp in self.transforms
> >     if type(temp) = "translate" then
> >       c = c + 1
> >     end if
> >   next
> >   if c > -1 then
> >     return c
> >   else
> >     return -1
> >   end if
> > end function
> > 
> > "transforms" being the "array" that is used to track "all" transforms
 
> > applied to that object in the original SDL step that created it, which
 
> > would be identical to the existing SDL. This doesn't prevent you adding
 
> > new transforms, either via the existing SDL method, or via the object
 
> > reference, or even *deleting* one that was previously applied (which 
> > isn't currently possible).
> > 
> > Hope that is clearer.
> > 
> You obviously miss a fundamental point: there is only ONE transform matri
x per 
> object that contain the SUMATION of every single transforms applyed to th
at 
> object. There is no transform array, there never was any such thing.
> Using an array of transforms would be wastefull. It would uselessly use e
xtra 
> memory. It would make rendering slow as the whole array will need to be c
omputed 
> for every ray that encounter the object, as well as any CSG operation tha
t use 
> that object. That array will need to be dynamic as you can never tell bef
orehand 
> how many transforms will be applyed to any particular object, adding some
 
> useless overhead, and requiring still more memory.
> 
And you are missing the point that you can't functionally work things 
that way in animation. Lets put it any other way, you have a matrix:

|0 0 0 1|
|4 3 1 0|
|1 0 2 3|
|5 2 3 0|

Or something, this is just random made up, but it serves the point. 
Where in that matrix is the "rotate this after moving it to point X, so 
that it acts like an arm, instead of rotating at the object center"? 
Even if you revert, you **still** have to then move it to the point on 
the object needed to rotate it, before also doing what ever else you 
need to make it work right. The fact that the cumulative matrix contains 
everything done to that point is ****meaningless**** from the standpoint 
of animation, because when animating you don't give a frack what the 
"final" result is, you want to render based on intermediary results, 
which changes that matrix "for every frame". If you revert it, you still 
have to keep track of what transforms you did, and in what order, so 
that you get the right matrix, which means you are **still** using up 
the memory to keep track of them in some fashion, while your seem to 
imagine that you can just wave a magic wand and have the memory issue go 
away. Either way, you have to reapply all the transforms "in each 
frame". I don't see how storing those in something that references them 
as part of the object they belong to does "anything" to change how much 
memory ends up being used.

Basically, you are still thinking in terms of a script that goes through 
in one pass, producing one "single" final result, which has to be 
rebuilt in the next frame. All objects in a script that doesn't reparse 
"never" reach that "complete" state you are going on about, they are in 
continual transition, so its not possible to just generate a static 
matrix, which automatically solves every problem. You still have to 
change that matrix in a way that produces the result you want, which 
isn't practical if you are working with an already transformed objects, 
which has multiple changes to the matrix, all of them interdependent on 
each other. And, even if you are right, I have yet to see you provide 
any example to prove either of us discussing the issue from our side of 
the line with proof that you are right and we don't get it. In fact, the 
only solution you can come up with is basically the same thing we are 
already saying, just separated from the object.

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