From: Dirk Lüsebrink (dirk++at++cantaloupe.de)
Date: 02/19/2000 05:35:45
Angus Dorbie wrote:
>
> I don't think intersection results are intended to be in depth sorted
> order.
>
> CHeers,ANgus.
but than how can you be sure not to walk into some object when the first
intersection
you get from the test is actually the intersection behind the wall with that
other object ?
a quite usual case is, I am standing hear and fly into a certain direction. i
just want
to know the closesest distance to the next osbtacle and then i construct my test
with the pick method of the pfchannel:
man pfChannel:
mode is a bitwise OR of tokens. In addition to those tokens that can be
specified to pfNode::isect in the mode field of the pfSegSet, the
following values are also allowed:
PFPK_M_NEAREST
Return the picking intersection closest to the viewpoint.
PFPK_M_ALL
Return all picking intersections.
PFTRAV_LOD_CUR
When traversing pfLODs, select the child to traverse based on
range in the specified channel.
When PFPK_M_ALL is set, picklist will contain all of the successful
picking intersections in order of increasing distance from the viewer
eyepoint.
which would be exactly what i want, but simply did not work reliable. anyhow,
just taking all
hits and sort them by the squared distance will do the trick. and as i said, i
was
also never able to reliable reproduce the case. i had the hunch, it was related
to some
kind of illegal generated geometry.
the man page is for pfchannel, stating the intersection are sorted. If the
implementation
of pfNode::isect is completly different than pfChannel::pick than of course the
assumption
of having the hits sorted would be invalid
dirk.
--
dirk lüsebrink fon +49 (30) 42 85 17 23 Cantaloupe|realtime
dirk++at++cantaloupe.de fax +49 (30) 42 85 17 24 Charlottenburgerstrasse 22
www.cantaloupe.de 13086 Berlin, Germany
This archive was generated by hypermail 2b29 : Sat Feb 19 2000 - 05:36:43 PST