Hi Pavel, Sorry for the delay, I'm now back at base.
I have looked at your code and the discussion on this thread and believe the original code is reasonable - one would normally expect the nearest objects in the scene to be picked and objects that occlude it would result in not activating the the manipulator. I do understand the special case where the geometry of object occludes the dragger geometry, so wonder if an tolerance value would be appropriate - so pick the first dragger entry that is no more than the tolerance value behind the first intersection. One could set this tolerance to FLT_MAX to get the behavior you've implemented or zero to get the present behavior, perhaps a small default tolerance would get round the in plane issues out of the box. The suggestion from Aurelien about using NodeMask/TraversalMask is a good one, it's a little orthogonal to the above approach but would make it possible to solve the problem as well. Thoughts? Robert. On 16 November 2011 09:51, Pavel Domsa <[email protected]> wrote: > > Issue: > Dragger receives ::PUSH event only when it is the closest object to camera. > In case of more complex composite draggers this is impossible to guarantee. > > File: Dragger.cpp / bool Dragger::handle(const osgGA::GUIEventAdapter& ea, > osgGA::GUIActionAdapter& aa) > > Detailed issue description: > > This is original code: > > if > (view->computeIntersections(ea.getX(),ea.getY(),intersections)) > { > > for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = > intersections.begin(); > hitr != intersections.end(); > ++hitr) > { > _pointer.addIntersection(hitr->nodePath, > hitr->getLocalIntersectPoint()); > } > > for (osg::NodePath::iterator itr = > _pointer._hitList.front().first.begin(); > itr != _pointer._hitList.front().first.end(); > ++itr) > > All intersections on event screen location are obtained and stored in > _pointer structure. > Then NodePath from *first* intersection only is scanned for node of type > osgManipulator::Dragger and if such node is found and matches *this* > pointer, then dragger->handle(...) is called. > > Problem is when dragger is for example TranslatePlaneDragger used for > manipulation of 2d text and both dragger and text are on same plane. > Then dragger doesn't need to be the first intersection found and original > code fails to process dragger->handle(...) even it's desired. > > Solution: > It's necessary to scan all intersections and use the first/closest > intersection with dragger in it's NodePath. > Variable closestDraggerFound in new code guarantees that only intersection > with closest dragger is evaluated > and this keeps logic as it was desired in original code. Only the closest > dragger gets chance to handle event. > > Testing: > Code tested in our application with complex composite draggers under many > conditions. Situations when more plane draggers > (from one composite gizmo) overlap tested. > > > > > _______________________________________________ > 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
