Justin A. McCune (jmccune++at++itd.nrl.navy.mil)
Wed, 25 Mar 1998 15:19:30 -0500 (EST)
We are having a problem with a multi segment intersection test involving
the discriminator function returning PFTRAV_TERM. For a given pfSeg in
the pfSegSet we would like to be able to terminate traversal for that
pfSeg without affecting the traversal of the other pfSegs in the set.
(By doing so we can optimize our line of sight determination.)
The Performer default discriminator action returns "PFTRAV_CONT |
PFTRAV_IS_CLIP_END", and functions completely correctly.
Our optimized discriminator function does nothing (except dumping debug
code) besides returning "PFTRAV_TERM | PFTRAV_IS_CLIP_END". The
optimized discriminator function seems to function incorrectly.
In our test case example, we have 5 pfSegs.
4 of the 5 line segments (differing positions, directions, and lengths)
should intersect the scene geometry at least once and in the case of
continued traversal, more times.
The correct results with default behavior: (CONT & CLIP_END)
we get 7 discFunc callbacks, for the 4 segments that are the
correct segments that should be intersecting the scene. The
other 3 callbacks are the results of a 2nd intersection.
With desired behavior: (TERM & CLIP_END)
(the CLIP_END is unnecessary and we have tried it without this)
we get only 2 discFunc callbacks in total. One per pfSeg.
Two of the 4 pfSegs which should intersect the scene geometry fail to
do so. Visually, we have Line of Sight rays going through walls.
There is no difference between the two cases in terms of scene geometry,
settings, positions, directions, LOD, etc. The only difference is the
return value of the discriminator function.
We have tried specifying face culling, LOD details, etc-- all of which
should be irrelevant to the test described above.
As far as we can tell the default behavior is always correct, though
more expensive in terms of time. Our desired optimization seems to
work only in the case of ONLY 1 line segment. With
more than one segment, however an incorrect number of intersections
is frequently returned.
We have tried this on Performer 2.0.4 Indigo2 and Performer 2.2 Onyx with
similar problems on both systems-- although the full battery of our tests
has been run mostly on the Onyx with Performer 2.2.
I -- thinking of course that my code is error-free, perhaps incorrectly--
suspect a bug in Performer, with Multi-segment, disc Function termination.
If this is the case and anyone knows this to be true, please let us know
so that we can fall back to the functioning but less optimal solution.
If we are incorrect in understanding how PFTRAV_TERM is supposed to work--
please explain. We've read the man pages, the insight books, we've cursed,
we'ver grumbled, we've banged our heads on the walls, and now we appeal to
the great gurus (who achieved guru status with trial by fire.)
Thanks for listening,
Justin
---------------------------------------------------------------------
Justin McCune HCI Lab, Code 5513
ITT Systems & Sciences Corp Naval Research Lab
(202) 767-5613
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:05 PDT