Hi Robert,
Robert Osfield wrote:
Hi Riccardo,
The intersection code doesn't know about the high level state
management of your application, so just sorts things based on the z
depth, and two CameraNode's each with their own projection matrices
will generate their own z ranges with may or may not overlap and may
or may not be in the ordering your expect. This means that picking
can produce results as you describe, but there isn't an easy low level
tweak to fix it.
The solution would be to do two picks, one for your 3D scene and one
for your HUD or to simply search the hit list and managed things
yourself.
I expected something similar, and go with 2 pick routines seems the best
solution.
But in the osgPick example, I've seen no specific code to handle the
cameraNode, it simply calls viewer::computeIntersection() -
hence I'm not able to "split" the 2 routines.
I checked all the osgProducer::Viewer::computeIntersection functions but
couldn't find anything -
and asking the numberOfCameras() the viewer is owning, I get 1 as an
answer.
Where should I look for the cameraNode pick routine??
Thank you
Ricky
Robert.
On 7/10/06, Riccardo Corsi <[EMAIL PROTECTED]> wrote:
Hi all,
in the osgPick example, when both a 3D model and the HUD are displayed,
the intersection with the HUD is reported as the last.
As "visually speaking" the HUD is always in front of the 3D model, I
would expect that hit to be reported as first, as it seems closer to the
viewer.
Is there a simple tweak to obtain this behavior?
Does it depend on some CameraNode implementation detail, or on what
else?
Thank you,
Ricky
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
