Re: [osg-users] [forum] Huge delays while mouse clicking with many draggers in scene
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] Huge delays while mouse clicking with many draggers in scene
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector gives incorrect results (intersections missing)
Dear Peter, Robert, and all. I would like to endorse Peter's remarks on the current implementation of the LineSegmentIntersector. We experience precisely the same problems when trying to pick on plane faces that coincide with the bounding box of the Drawable to which they belong. The simplest example is a drawable consisting of one triangle or quad aligning with the axes of the local coordinate frame. Like Peter, we are also dealing with co-ordinate values running into the thousands. The applied epsilon of 1e-4 in the intersectAndClip() function is too small in suchlike cases, especially if the TriangleIntersector keeps using floats at some places. For the moment, we circumvent the problem by overloading the computeBound() function of the Drawable and return a slightly bigger bounding box ourselves, but a more general solution would be better in the end. Like Peter, I also do not see why the intersectAndClip() function should cut off those parts of the line segment that are outside the bounding box. What is the computational benefit of this later on? I would expect it is sufficient to check whether the line segment is crossing the box or not, and neglect Drawables for which the answer is false. However, assuming that this clipping does serve a goal, then my choice would be not to assign the epsilon in the intersectAndClip() function an absolute value, but to make it relative to the bounding box size, for example by multiplying the current epsilon of 1e-4 with the diagonal length of the bounding box. Best regards, Jaap Glas dGB Earth Sciences Enschede, The Netherlands -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54027#54027 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
