Hi Pavel, I haven't seen a reply to my post below, or the other posts on the thread on osg-submissions about your submission. Current status now is that I've merged Aurelien's change for support of using node masks in osgManipulator as this approach doesn't have any downsides like your changes. If we are to integrate changes for making the considering other interestections other than the nearest then we'll need to use an approach that uses tolerances as I suggest below.
Could you let me know whether Aurelien's changes work for you? If so I'll discard this submissions as unnecessary, if not then we'll need to come up with a new submissions that address the issue of constraining the intersections considered as I have suggested. Cheers, Robert. On 23 November 2011 09:48, Robert Osfield <[email protected]> wrote: > 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
