In article <3f1d8d00@news.povray.org>, dar### [at] earthlinknet says...
> In your nested structure you still have to pose each item and position it
> onto the end of its parent.  The result is an object which you then
> transform again, etc.  All I did was use a macro to combine the transforms
> in ataLens into a single transform in ataMoves for each arm segment.  You
> don't have to "make adjustments by hand"-- the ManipArm macro makes them for
> you.  The posing transforms need to be watched in both systems, however.
> 
Yes, but you can just as easily use an array to keep track of each 
rotation. However, in both cases you end up having to remember 'which' 
set up data belong to what item in such a case. Unless you have an 
external program that shows and and keep track of all these, you are 
better off having all leg motions in one array, arm motions in another, 
etc. If everything is stored this way you have a big bloody mess, 
especially if you drop the project for a few months and then come back 
and realize you haven't a clue what belongs where or why. ;) Maybe 
something in between would work better.

> The issue I have with nesting comes from what I suspect are limits within
> POV-Ray on the number of nested levels you can have.  It's not that nesting
> is inherently wrong; it actually works for simple models.  But heaven help
> you if you want to build a millipede using nesting.
> 

Not necessarily.. I think it is 'levels' of nesting that are an issue, 
not the total objects you nest. For a millipede you are looking at 
roughly 4 layers for the legs and a body segment. If the body itself is a 
spline, then you could use a surface trace or some other method to locate 
each pair of legs (which makes it exactly 4 levels, not including extra 
segments for antennae). Unless you are a total fool, you end up with a 
nesting level of no more than 4-5 levels maximum. I frankly can't think 
of anything that should require extreme amounts of nesting (though this 
won't stop someone from doing it). At worst you might have some object 
you don't want to move, but still be attached to a level above and that 
would add an extra sub group at 'that' nesting level. I could be wrong 
about how the limit works. But one thing I do know, it is a bad idea to u 
unnecessarily complicate a model by dumping the whole thing into an array 
where the most someone, who doesn't have graph paper and lots of 
patience, can say is 'well that object is located somewhere in the 
model...'. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message