Hi Robert,
I believe Aurelien's changes would work for us too. I haven't got to
implementing via nodemasks in our code yet.
You can discard submission.
Thanks
Pavel
On 2/8/2012 10:44 AM, Robert Osfield wrote:
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
