lots o' moving models on the scene

New Message Reply Date view Thread view Subject view Author view

Lance R. Marrou (marrou++at++vsl.ist.ucf.edu)
Thu, 8 Dec 1994 17:41:27 -0500 (EST)

I have question about optimizing performance. Someone mentioned before,
though I am not sure who, that reorganizing the scene graph into something
like an octree would be best. Although this makes complete sense for a
static scene graph, I want to know if y'all think it would also work better
for lots of moving models.

COMMENTS:

First, whenever a a moving model is updated, its parent's bounding volume
may also need to be updated. This means that if, say, 20 models are in one
section of the octree, then whenever one of the models gets updated, that
octree section gets updated for all 20. Of course, the octree may have
lots of subsections, which further increase the number of bounding volumes
which get updated.

Does Performer utilize a smart algorithm for updating bounding volumes under
PFN_BMODE_DYNAMIC? That is, if we only translate a model, will its bounding
volume merely be translated (and its parent's and so). Does it check for
single children (thus just copying the child's bounding volume, rather than
recomputing it).

I am just curious if I might get some more performance for the time it takes
to write the octree code. Also, some of that octree code may need to be
special ordered based upon answers I get.

Obviously, if there are only a few moving models, it makes sense doing a
complicated octree. I do not know how many models it would take to make it
worthwhile. Any ideas?

Thanks. :)

_______________________________________________________
                         E-mail: marrou++at++vsl.ist.ucf.edu
IST __ WWW: http://www.vsl.ist.ucf.edu/~marrou
Visual / / ______ /\____ ______ ______
Systems / / / _ / / __ // ____// ____/
Lab / /__ / /_/ / / / / // /___ / __/_ R. Marrou
________/____//____/\\/_/ /_//_____//_____/____________

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:43 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.