Re: Problem with isector intersection test against the scene graph

New Message Reply Date view Thread view Subject view Author view

From: Angus Dorbie (dorbie++at++sgi.com)
Date: 02/21/2000 09:38:12

The sorting PFPK_M_NEAREST is added by the channel pick method, you
can't expect the lower level isect routing to know about these. If you
use channel picking you can use these tokens, if you use node isectors
directly you can't. The implementation isn't completely different, the
pick uses the isector and adds functionality, obviously you can't just
take that added pick method functionality and expect it to work directly
with the isect method.

Cheers,ANgus.

Dirk Lüsebrink wrote:
>
> 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
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com 

-- 
For Performer+OpenGL tutorials http://www.dorbie.com/
My comment on the abuse of Jon Johanson's rights;
After giving up raiding their neighboring countries the Norse men
have taken to raiding 15 year old kids in their bedrooms. Very sad.

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Feb 21 2000 - 09:38:46 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.