Re: [osg-users] Viewer thread safety question
Uh, sorry, how could this end up as a reply ? Please ignore, I'll repost. Cheers, PP On 10/12/2011 9:41 AM, Chris 'Xenon' Hanson wrote: On 10/12/2011 8:31 AM, Joshua Cook wrote: To make a long story short COIN was failing in a bad way but the standard notify message at the INFO level is: DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll Warning: Could not find plugin to read objects from file ../../some_file.iv. So, I know that COIN's failure is not an OSG problem but I do believe there may be room for a more useful debug output when a dll has problems that don't revolve around not existing. Are you 100% sure the DLL _is_ actually loading but the IV file fails to load? How have you verified this? You can set breakpoints in the DLL, or use something like SysInternals' ProcessMonitor to snoop on successful (and unsuccessful) DLL loads. Assuming the error message is correct and the plugin isn't being found... osgWorks has an app to find plugins. I don't have the .iv plugin, but here's an example of using it to find the .flt plugin: osgwwhich -p flt Using plugin name: osgPlugins-3.0.1/osgdb_openflight.dll. C:\Program Files\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_openflight.dll You can also set OSG_NOTIFY_LEVEL=DEBUG_FP to have OSG print each path that it searches to try to find the plugin. Hopefully these two tricks will help you figure out why OSG is claiming it can't load the plugin. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
Hey, I appreciate the advice from everybody and have implemented a lot of it as it will help me develope better code. However, my original problem does not stem from thread safety but from the .IV plugin and COIN. We discoved this before I left for the day and I believe this may be an issue to be looked into. Here is what was happening. When I tried to load up .IV files using Inventor and COIN the plugin would fail along the way. Most times the failure would only return a NULL pointer and I would be led to believe, by the notify messages, that the plugin simply could not be found. However, when we started messing around with the order of operations and a few other parameters we noticed that the crash was only taking place when attempting to load a .IV file. The reason I thought this was a threading issue is that the call stack made it look like one of the internal vectors had been corrupted by another thread. But, since the only thing that was happening at this time was failing to read a .IV file we figured something was not quite as it appeared. To make a long story short COIN was failing in a bad way but the standard notify message at the INFO level is: DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll Warning: Could not find plugin to read objects from file ../../some_file.iv. So, I know that COIN's failure is not an OSG problem but I do believe there may be room for a more useful debug output when a dll has problems that don't revolve around not existing. My largest problem is that I'd love to tackle this myself but the legal I'd have to go through here would take at least 6 months. So, it is here for discussion and if you think that 6 months + time to fix this wouldnt be that bad I could put in for permission to contribute to the project and hope they approve it. Thanks, soulsabr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43353#43353 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/12/2011 8:31 AM, Joshua Cook wrote: To make a long story short COIN was failing in a bad way but the standard notify message at the INFO level is: DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll Warning: Could not find plugin to read objects from file ../../some_file.iv. So, I know that COIN's failure is not an OSG problem but I do believe there may be room for a more useful debug output when a dll has problems that don't revolve around not existing. Are you 100% sure the DLL _is_ actually loading but the IV file fails to load? How have you verified this? You can set breakpoints in the DLL, or use something like SysInternals' ProcessMonitor to snoop on successful (and unsuccessful) DLL loads. DLL paths and version number issues are very common in OSG installations. Also, consider switching to 3.0.1 if you haven't already. 3.0.0 had some quirks. I have 3.0.1 binaries built and on my webserver but I don't think I've updated the links. I'll try to get them up there today. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/12/2011 9:41 AM, Chris 'Xenon' Hanson wrote: On 10/12/2011 8:31 AM, Joshua Cook wrote: To make a long story short COIN was failing in a bad way but the standard notify message at the INFO level is: DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll Warning: Could not find plugin to read objects from file ../../some_file.iv. So, I know that COIN's failure is not an OSG problem but I do believe there may be room for a more useful debug output when a dll has problems that don't revolve around not existing. Are you 100% sure the DLL _is_ actually loading but the IV file fails to load? How have you verified this? You can set breakpoints in the DLL, or use something like SysInternals' ProcessMonitor to snoop on successful (and unsuccessful) DLL loads. Assuming the error message is correct and the plugin isn't being found... osgWorks has an app to find plugins. I don't have the .iv plugin, but here's an example of using it to find the .flt plugin: osgwwhich -p flt Using plugin name: osgPlugins-3.0.1/osgdb_openflight.dll. C:\Program Files\OpenSceneGraph\bin\osgPlugins-3.0.1\osgdb_openflight.dll You can also set OSG_NOTIFY_LEVEL=DEBUG_FP to have OSG print each path that it searches to try to find the plugin. Hopefully these two tricks will help you figure out why OSG is claiming it can't load the plugin. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Viewer thread safety question
Ok, so I have the unenviable task of rewriting software from the mid 1980's for our virtual reality/cave environment and while I'm rewriting all of this software I must make sure that it works with the older software so that operations can continue as before; yes, welcome to my world. The system consists of over twenty different units each of which communicates with each other constantly via UDP and the first of these things to go is the viewer that was written using OSG .9x. My viewer must request a dump of all file names and then wait for an end of dump message before I start rendering the scene. However, since this is UDP and since there is no telling what the older software is doing (the older code uses void* like the fire department uses water) it ends up sending the packet with the file name to the wrong computer, fails to send the packet, or UDP just fails to make that left turn at Albuquerque and the packet is lost forever. So, now I need to request a resend and load all of the missed data into an actively running scene graph where every node is a leaf (I'm working on getting them to fix that part). My viewer runs its own update loop in which it will computer inputs, compute other changes in the scene, and then check for any new nodes that have been received before calling the frame() function. Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? And just in case you're wondering, I'm replacing the viewer first because it crashes the most of all of the other systems. Thanks, soulsabr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43336#43336 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
Hi ?, How frequent of an occurrence is the need to add/remove portions of the scene graph? And what kind of performance are you looking for as it happens? If it is infrequent, could you simply stop threading on the viewer, modify your scene graph structure however you need to, and start threading again (and your frame loop) after you're done? I've used an UpdateCallback in the past to add/replace nodes while the viewer is running. It wouldn't be particularly difficult to go this route (subclass from NodeCallback, use whatever threadsafe mechanism you want within the class to synchronize with your incoming data, and when needed add a child to a group node which has the callback attached). You could test the performance of it in your application, which is more important than what anyone can speculate about. Cheers, Tom -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43341#43341 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/11/2011 2:00 PM, Joshua Cook wrote: Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? Well, it's somewhat inefficient if you run the viewer multithreaded, but the way that it's inefficient is kind of irrelevant in your situation since it seems like you'll have to incur that inefficiency no matter what because your graph is potentially dynamic on every frame. Basically, in my mind, no trick will ever avoid the fact that you have to wait for rendering to completely finish before modifying the graph. There might be some devious trick that could allow otherwise (maybe two copies of the graph and you stagger the accesses and the visibility of them?) but premature optimization is the root of lots of bad things. Just do it the proper way now, and see if the performance is really a problem or not, and deal with it then if it is. And just in case you're wondering, I'm replacing the viewer first because it crashes the most of all of the other systems. Wise choice. Thanks, soulsabr -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
On 10/11/2011 2:00 PM, Joshua Cook wrote: the wrong computer, fails to send the packet, or UDP just fails to make that left turn at Albuquerque Ooo! A Bugs Bunny reference. :-) Since the root node of the scene may constantly change I was just thinking of making its variance DYNAMIC. Of course that has been touted as very inefficient and I agree with that. I had looked at inheriting from osg::Drawable::UpdateCallback but figure that I'd have to make the varience DYNAMIC anyhow so it wouldn't matter. So, my question is, would there be a better way to make this thread safe other than setting the root node to DYNAMIC to avoid crashing when adding another node to the root? Honestly it sounds like you have a lot worse things to worry about right now than efficiency. If I were in your shoes, I'd get it working and working right first, then tune later. I'm pretty sure that setting osgViewer::Viewer::setThreadingMode(osgViewer::ViewerBase::SingleThreaded) will allow the draw thread to complete before Viewer::frame() returns, which should allow you to add/remove nodes to/from your scene graph. Give that a try. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewer thread safety question
Hi Joshua, I'm wondering, have you tried just adding / removing nodes in your graph before calling frame() on your viewer? The Draw traversal, which may still be running when the previous frame() returns, should theoretically not care about changes in the graph. That's because the cull traversal gathers statesets and drawables into its own lost, stored in ref_ptrs, and then the draw phase dispatches the draw calls for those based on the list gathered during cull. But when frame() returns, cull is finished, and update for the next frame hasn't started yet, so it should be safe to modify the graph at that point. Any nodes you remove from the graph don't matter since draw has stored all the drawables and statesets (that it needs) in ref_ptrs. And no other traversals are running (draw is not technically a traversal, since it has its own list and doesn't traverse the graph), so no iterators will be invalidated by adding or removing children in your graph. The DYNAMIC data variance only applies to drawables and statesets, for that same reason. It's those things that the draw traversal may be using at the same time as another thread, so it's those things that need to be dispatched before frame() returns. The things that need special care are adding / removing views in a CompositeViewer, or replacing the graphics context on a camera, or things like that. For those, you'll generally have to stopThreading() before, then startThreading() after the operation, to make sure no draw threads are running when you do them. But changing the graph can safely be done between calls to frame(), that shouldn't be a problem. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
