Thanks Robert, It's OK to use RayIntersector for the case of unbounded ray intersection with depth-partition scene and embedded cameras. But my submission just want to return to users the correct global near/far values. For depth partition case, we can manually traverse all slaves and collect them. But for embedded camera case, it seems to be a difficult mission, because currently near/far values computed in cull visitor will neither be re-set to the last camera in stack, nor to the main camera of the viewer.
So I think we should at least find a way to return the computed near/far values to user level, for further debugging and testing. Do you think it a better alternative to set the near/far values to the owner camera in CullVisitor::popProjectionMatrix()? BTW, I just found that there were a few topics about the FBX plugin updates. Would it be confusing for you to review and accept them? Do you need some help like collecting all past submissions and resubmitting a complete one? :-) Wang Rui 2013/2/15 Robert Osfield <[email protected]> > 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 >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
