In article <470ec586$1@news.povray.org>, dne### [at] sanrrcom says...
> Warp wrote:
> > 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 transformati
on 
> >> 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.
> 
> Sure. I'm not the one advocating that every object gets such an array. 
> :-) I'm just pointing out that some of the objections are mistaken. 
> Arrays you can index by objects and into which you can store anything 
> (including transformations) would seem to be the obvious way to go.
> 
Why? Its going to cost you more memory to store 20 transforms for an IK 
chain, and all changes needed for them, in separate arrays, than it will 
to store 20 transforms in the object, then apply only 3-4 changes from 
"your" array, which are needed to change the specific parts that are 
needed. One uses, lets say 20*5, just to pick an arbitrary number for 
the storage needed, + 4*5*number of changes. Yours requires 20*5*number 
of total changes you need. If the number of changes are say 10, then 
mine takes 20*5 + 4 * 5 * 10 = 300, yours takes 20*5*10 = 1,000. How th
e 
heck is that "better"? Mind you, this is a "simple" example. It only 
gets worse if it something that has 10 IK change points, and 90 objects. 
In that case its 90 * 5 * 10, or 4500 for you, and 90 * 5 + 10 * 5 * 10, 
or 950 for mine. Its only *equal* if every object has to have "every" 
transform changed between frames, and thus all of them replayed into the 
object. The more objects that are part of the IK design, the more insane 
your number gets, while mine only grows depending on the number of 
"specific" transforms you need to change during animation, plus the 
total number of original transforms.

Yes, it would be nice to have a solution that doesn't require any such 
thing to start with, and you can get by with that, to some extent, by 
having a function call to something that determines the next change, 
instead of a straight change. I have not however seen anything to 
convince me that "some" sort of solution similar to this isn't needed. 
At least not unless you throw out the entire old SDL and force everyone 
to use "your" solution to apply all the transforms all at once, every 
frame, which means abandoning the original SDL, since it can't currently 
work that way.

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