Sharon Clay (src++at++rose.asd.sgi.com)
Tue, 30 Apr 1996 02:03:43 -0700
If you don't absolutely have to have results every frame, you might consider
forcing a forked intersection process so that if the intersections
take a long time, they won't be so likely to hold up the drawing.
->
->Originally the geometry was a couple of giant geosets. We have the tools at
->hand to slice and dice them-- Alias as well as Designer's Workbench. My
->first inclination is to break the data up into hierarchically arranged
->zones like octrees but since I know the geometry (which is not equally
->distributed in space) I can manually, though laborously, group it more
->efficiently than that. There are passageways between sections of the
->geometry also but the geometry is not planar so the pfPortals package won't
->help me here. We'll probably try using fog to move the far clip in and
->limit extra drawing.
->
->My reasoning for this arrangement is that if I understand properly how
->Performer's intersect routines for a pfSegSet work, then I will quickly
->find the geoset(s) that are candidates for an intersection by Performer
->doing bounding volume checks hierarchically (I will have nested groups).
->Once the few small bounding volumes down at the bottom of the hierarchy are
->found polygon intersection checks will be done to find the actual contact
->point(s).
This is true. And, if you use pfPartitions, your search for the proper
pfGeoSet will be _very_ fast indeed.
->
->I am assuming that this is the fastest possible way to do intersects for
->this situation because:
->
->1. Checking bounding volumes is much faster than polygons -- Performer does
->as much bounding volumes as it can before dropping to polygon checks.
->2. Performer is automatically smart about working its way down through a
->hierarchy of bounding volumes -- look at the top level hierarchy bounding
->volume, if a segment touches it check its children's bounding volumes and
->continue on only those that touch the segment then check their children's
->bounding volumes, etc. until a list of the geoset bounding volumes touching
->the segment is constructed.
->3. Performer will not do polygon intersections until the list of bounding
->volume geosets has been selected in a "first pass" by Performer.
In addition, you can provide an enclosing cylinder around your segset which
we will test before doing segment intersections. If you can group together
a bunch of simillarly directioned segments, this can provide another major
speedup.
->
->I am curious what the tradeoff between nesting and number of polygons in a
->geoset should be... should I shoot for 10 polygons in a geoset ? 5? 20? 50?
->Will drawing speed become more of a limiting factor than intersections at
->some point because of inefficient tristrips ?
Since the size of pfGeoSets is also going to effect your drawing efficiency,
you don't want them tooo small. I'd say a minimum of 12 tris per
pfGeoSet and this is really assuming that you are on a low-end gfx system
that is not easilty host limited. Since you say you are on an IMPACT, I'd
expect that you are more likely fill limited. Generally, for high-end
systems, I'd say the good range is more like 24-64 tris.
->
->The final complication is that my camera actual has a long cord behind it
->(think of snaking a cable through an irregular maze) which must be
->continuously checked against the geometry for intersections. This means
->that there are a number of segments that must be check. The question here
->is:
->
->Is it better, in terms of intersection calculation efficiency, for the
->above geometry to check:
-> 1. one pfSegSet with all the segments for all the joints of the cord in
->it against the entire scenegraph
-> 2. check each segment individually with its own pfSegSet against the
->entire scenegraph
-> 3. use on pfSegSet with all the segments but mask it for each segment a
->check once for each segment against the scenegraph
If the segments have reasonable spatial locality and direction, put
them together and put a cylinder around them.
Otherwise, use partitions and do them separately so that you don't have
to intersect lots of polygons with segments that have no chance of making a hit.
One might also ask if _all_ of the segments require polygon intersection
information - maybe for some segments you can stop at just PFTRAV_IS_GEODE
for bounding sphere or PFTRAV_IS_GSET for bounding box intersections for
setting your pfNodeTravMask().
Also, I am sure that you know this but just to be complete, be sure
to enable isect caching on static pfGeoSets with the PFTRAV_IS_CACHE bit
set in your setMode to pfNodeTravMask().
I hpoe this helps,
src.
--
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com (415) 933 - 1002 FAX: (415) 965 - 2658 MS 8U-590
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:49 PDT