Hi Rui, I have just done a review of your change for a GlobalNearFar and it feels rather awkward and confusing to me. I don't have an alternative proposal right now, other than the suggests for cases where we have multiple Cameras overlapping and wish to using picking then one should use an unbounded ray intersection test rather than a line segment test. W.r.t RayIntersector submissions, I'm still trying to work my way through my submissions backlog.
Robert. On 13 February 2013 08:33, Wang Rui <[email protected]> wrote: > Hi Robert, > > I'd like to submit my changes to fix the "near/far values for intersection" > problem, which can be obviously found in osgdepthpartition and osgpick (with > the option --relative-camera-scene) examples. > > In the osgdepthpartition example, we can't actually perform correct > intersection test (in WINDOW/VIEW/PROJ coordinate frames) with earth/sun > nodes because the necessary near/far values are stored in slaves instead of > the main camera. I provide a new computeGlobalNearFar() method in ViewerBase > to obtain a global near/far pair and apply it to the main camera, and update > the osgdepthpartition example to show how it works. > > In the osgpick example with --relative-camera-scene, you will see that when > picking the cube object, only one result is returned (but of course there > should be two). That's because the cube is drawn under a post camera in the > scene graph. The CullVisitor will reset old near/far values every time when > it finishes traversing a child camera, so the depth data of the cube is > already lost when we apply getCalculatedNearPlane() and > getCalculatedFarPlane() to the main camera in SceneView::cull(). I changed > this behavior by providing the getGlobalNearPlane()/getGlobalFarPlane() > methods, and now osgpick can work with correct results. > > The computed result may not satisfy everyone as it collect all perspective > projection matrices to get a global near/far pair. But in some cases we may > want to ignore some of them (e.g., RTT camera matrices). This can be done by > providing an extra option to the Camera/Projection classes. But at least my > changes should not affect the rendering work and should be compatible with > most current applications. So I'm glad to submit them now. :-) > > Some months ago, you, PCJohn and me discussed about the idea of infinite > line intersection (seems that for design pattern reason the RayIntersector > is not merged to the trunk yet). It could also fix the intersection problem > in large environments. But the correct near/far values are still not > returned to users, which may be very useful for debugging and implementing > frustum-related algorithms. I hope this patch could help. > > Cheers, > > Wang Rui > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
