Dwight Meglan (dwight++at++ht.com)
Wed, 17 Apr 1996 14:54:04 -0400
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).
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.
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 ?
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
I don't want to write code to do frame-to-frame coherence yet-- that comes
later if I find that the straight forward approach of ignoring the previous
frame's results is too slow.
Thanks in advance for advice on this.
BTW, I did a large collision implementation under Performer a couple
months back and ended up doing my own isects because I could use a segment
to cylinder intersect for that situation. It was probably 10x faster than
the Performer polygon-based isect. But I cannot do such tricks this time--
the geometry is too irregular.
--dwight
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dwight Meglan, PhD | Developers of complete surgery simulation
Engineering Coordinator | training systems and surgery simulation
High Techsplanations, Inc. | creation software tools
6001 Montrose Rd., Suite 902 |
Rockville, MD 20852-4874 | "Witty, yet erudite saying goes here..."
301 984 3706 x38 |
301 984 2104 : FAX |
dwight++at++ht.com | http://www.ht.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:44 PDT