|
 |
In article <3f1d8d00@news.povray.org>, dar### [at] earthlink net 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
|
|
|
|
> I think it is 'levels' of nesting that are an issue
I've tried 1500 nested rhombododecahedrons: it works, but took
over 20 minutes of parsing time at 1 GHz because *all* objects
nested so far have to be transformed at every level, making the
time required for transformations proportional to the square of
the levels (when objects of comparable complexity at every level
are nested). 50 rhombododecahedrons take only 1 second, so very
complicated robot arms or even chains are easily possible with
the nesting method.
Sputnik
Post a reply to this message
|
|
|
|
Hi Tim Nikias v2.0, you recently wrote in povray.advanced-users:
> Anyone got any reference links I could begin with?
I don't have the link, but Game Developer Magazine had an excellent
series (with basic source code) that illustrated the concepts very
nicely.... try www.gdmag.com and see if you can find it....
- Lutz
email : lut### [at] stmuccom
Web : http://www.stmuc.com/moray
Post a reply to this message
|
|
