OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Huge delays while mouse clicking with many draggers in scene


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General [forum]
View previous topic :: View next topic  
Author Message
jaap_glas_dgb
Newbie


Joined: 15 May 2013
Posts: 6

PostPosted: Wed May 06, 2015 4:49 pm    Post subject:
Huge delays while mouse clicking with many draggers in scene
Reply with quote

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
Back to top
View user's profile Send private message
cbuchner1
Appreciator


Joined: 14 Mar 2012
Posts: 303

PostPosted: Thu May 07, 2015 8:38 am    Post subject:
Huge delays while mouse clicking with many draggers in scene
Reply with quote

We've run into a very similar issue recently, with hundreds of inividually movable objects in a scene.


Our ugly workaround was to require a modifier key, e.g. Alt to be pressed if one really intended to move

an object. So at least the camera controls when not pressing the modifier remained smooth.



I would also be very interested in seeing some optimization to the way draggers compute their intersections.


Greetings,



   Christian






2015-05-06 18:49 GMT+02:00 Jaap Glas < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)>:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 10855

PostPosted: Thu May 07, 2015 8:56 am    Post subject:
Huge delays while mouse clicking with many draggers in scene
Reply with quote

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:
Quote:
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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
jaap_glas_dgb
Newbie


Joined: 15 May 2013
Posts: 6

PostPosted: Mon May 11, 2015 10:37 am    Post subject:
Re: Huge delays while mouse clicking with many draggers in scene
Reply with quote

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:
Quote:
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








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General [forum] All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Recommended way to render a scene fro... Hannes Naude General 6 Tue Apr 11, 2017 11:12 am View latest post
No new posts Covert and use 3ds Max scene to OpenS... lucia General 0 Mon Mar 06, 2017 9:19 am View latest post
No new posts How to handle cameras in the scene gr... wernerM General 7 Fri Feb 24, 2017 4:47 pm View latest post
No new posts Minor issue with GraphicsWindowWin32.... loopy General 0 Mon Jan 23, 2017 10:18 pm View latest post
No new posts Visualizing a light cone in scene suraj General 7 Tue Jan 10, 2017 10:44 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP