In article <470dec42@news.povray.org>, war### [at] tagpovrayorg says...
> Darren New <dne### [at] sanrrcom> wrote:
> > > It would make rendering slow as the whole array will need 
> > > to be computed for every ray that encounter the object, 
> 
> > Nonesense. Once the tracing starts, you compute the final transformatio
n 
> > matrix, just like you do now when there are multiple transforms.
> 
>   It's not a question of efficiency, it's a question of not hard-coding
> one specific solution where no such hard-coding is necessary at all.
> 
>   (Besides, it *is* a question of efficiency too: Those arrays will
> consume extra memory which is not necessary to be consumed. This may
> become an issue with millions of objects.)
> 
Your solution **still** requires extra arrays, or code, or **some** way 
to get the changing data "to" the object to transform it. If anything, 
as I try to explain in another post, your method is actually **more** of 
a memory hog. You keep claiming that you can just somehow "untransform" 
the matrix, or change it later, even when doing something like 
translate->rotate->translate irrevocably creates conditions where its no 
longer as simple as just adding one new rotation. Some how you have to 
both save memory "and" provide a way to change interdependent 
transforms, which, unless you are a fracking mathmatician, isn't going 
to be practical. any solution you come up with, at minimum, is going to 
require some transforms to be user changable, after the fact, and 
keeping **all** of them in an array, to be applied later, is **worse** 
that keeping all the of the initial states on the object, then just 
changing the one you actually need to.

I haven't seen any argument from you that does a thing to truly address 
that issue.

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