Dear all, I agree with Robert that the whole scene has to be tested to avoid picking obscured draggers. But this will not be a real computational burden if it would happen only once for every new event. As long as it is not redone for every dragger again.
I am aware that the original dragger code was made by others. And our current workaround works fine for us. We do not need an immediate fix. The main reason to post it on the forum is to signal that the problem exists and to share our findings with others that may search for an explanation or a solution. Best regards, Jaap Glas -- dr Jaap C. Glas -- Software Engineer -- dGB Earth Sciences -- Phone: +31 53 4315155 -- Email: -- Internet: dgbes.com & opendtect.org robertosfield wrote: > Hi Jaap, > > The whole scene is tested so that obscured dragger don't get picked > unintentionally. Each dragger doing the same intersection traversal > is inefficient though, athough as I'm not the original author of > osgManipulator I'd had to do a code review to look at all the > possibilities and consequences. I'm current deep in another complex > part of the OSG so don't have the spare brain capacity or time to do a > review right away. > > Cheers, > Robert. > > On 6 May 2015 at 17:49, Jaap Glas <> wrote: > > > Dear all, > > > > I am an employee of dGB Earth Sciences, and we use OpenSceneGraph for > > the 3D visualization of our open-source seismic interpretation package > > OpendTect. > > > > Our scenes may sometimes contain hundreds to thousands of draggers, mostly > > Translate(1D/2D)Draggers. We found that mouse clicking in the scene becomes > > very slow in that case. It turns out that every OSG dragger tries to > > intersect > > the line from camera eye to mouse position with all objects in the scene in > > order to produce its private list of intersections: > > > > [osgManipulator/Dragger.cpp:371] > > if ( view->computeIntersections(ea ,intersections,_intersectionMask) ) > > > > My question is whether this is really necessary? I don't see (yet) why > > this list cannot be calculated only once and shared by all OSG draggers. > > Or alternatively, only calculated for draggers that are located under the > > mouse pointer. > > > > Our current workaround consists of derived dragger classes that overload > > the Dragger::traverse(.) function to test this latter alternative in > > advance, > > passing the current node path as an extra parameter: > > > > if ( !view->computeIntersections(*ea,nv.getNodePath(),intersections, > > _intersectionMask) ) continue; > > > > This reduces the computational order of mouse clicking from quadratic to > > linear with the number of draggers in the scene. And mouse clicking in the > > scene can be done again without huge delay. > > > > However, the question is whether such a shortcut would apply in the general > > case. Why is the osgManipulator::Dragger class doing this the way it does? > > > > > > Best regards, > > > > Jaap Glas > > > > > > -- dr Jaap C. Glas > > -- Software Engineer > > -- dGB Earth Sciences > > -- Phone: +31 53 435155 > > -- Email: > > -- Internet: dgbes.com & opendtect.org > > > > ------------------ > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=63651#63651 > > > > > > > > > > > > _______________________________________________ > > osg-users mailing list > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ------------------ > Post generated by Mail2Forum ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63699#63699 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
