Michael Jones (mtj++at++babar)
Mon, 7 Feb 1994 08:39:09 -0800
This is really Jim Helman's question, but I'll give it a shot...
:The application is line of sight & occulting calculations, if a
:pfSegsIsectNode is used on a vector between two moving objects
:they want to test for terrain intersections. It works but there
:are many intersections being returned and they only need to wait
:for the first terrain intersection so they are looking to improve
:performance.
:
:They specify a discriminator callback which prints a message that
:it has been called and returns PFTRAV_TERM.
:
:However the callback is invoked multiple times for each intersection
:instead of just once.
[before we even start: you are specifying CLIP_END, right? and isect
caching is on? make sure before proceeding...]
I presume that you mean "...callback is invoked multiple times for
each intersection _search_ instead of just once."
Given that the database is not sorted into a total order in the BSP
sense, we must look at all "possible" nodes for each intersection.
Possible nodes are those whose bounding volumes are closer at some
point along the search vector than the closest known intersection.
Here's the idea (boxes represent bounding volumes):
*
+-------------+
+------|--+ |
seg: --------|------|W-|-------S--|----------------->
| +----- B -----+
+--- A ---+
Now if the first node tested in the search is A, and the intersection
is found at point W, we still need to test node S, since it's bounding
volume extends closer to the origin of the search vector than the
closest known intersection point. (This fact is indicated by the small
asterisk)
The result of searching node B is in this case point 'S', which is seen
to be more distant and will thus be discarded.
:Is this a bug or a mis-understanding of the man page ?
Performance oriented customers (which is just about everyone) can get
best performance by minimizing the overlap of nodes. How is this best
done? By organizing the database spatially: form a quad-tree or oct-tree
like hierarchy with your data. If the nodes A and B above had not been
in overlap, there could have been but one search. Also, make sure that
your geosets are not too big: 5 to 50 polys makes sense, but thousands
of polygons in a geoset can be dangerous since the intersection test
must be performed on _each_ primitive in the geoset whenever the set's
bounding volume is hit by the vector.
For even greater performance in intersection processing, look to IRIS
Performer 1.2, which has these important new intersection features:
1. pfPartition node for direct spatial indexing into an automatically
built grid-like search structure.
2. parallel intersection processing to let extra CPU's be used for
correspondingly greater intersection throughput.
--Be seeing you, mtj++at++sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:10 PDT