Cool - I'll give the update a shot. Thanks for your help, AC
On 9/16/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > HI Adam, > > I would recommend updating to the SVN version of the OSG. I have > removed the use of the DeleteHandler replacing it with use of > ref_ptr<> in the osgUtil rendering backend. Performance wise this > results in a small hit on cull performance, but does make the clean up > my cleaner. If you are using ref_ptr<>'s in your own subclassing > properly then everything should just clean up without need to any > special ordering. > > As for timing, changing for STATIC to DYNAMIC can potentially cause > problems. One should wait till all the objects have been dispatched > before changing, alas as yet there isn't a convenient way provide for > this. If you plan on changing things to DYNAMIC in your app just set > them to DYNAMIC to begin with. > > W.r.t deleting/adding this should not be any issue as ref_ptr<> will > ensure things hold together (especially in the SVN version of the OSG > with the above change). > > Robert. > > On 9/15/07, Adam Coates <[EMAIL PROTECTED]> wrote: > > Hi, Robert, > > > > I drive the viewer myself via osgViewer::frame(), so all of my updates > > happen outside the traversals. Thus, anything set to STATIC was > > off-limits, even up to the point that my osgViewer was deleted by the > > destructor of the object containing it. I destroyed some internal > > data belonging to my own Drawable subclass before this point, not > > realizing that it could still be getting called while the Viewer was > > living. What I meant by the "hang" was that the Viewer was sitting in > > a loop waiting for the OperationsThread to cancel because it was > > calling my Drawable, which already had its data destroyed, thus > > causing a crash. > > > > So, the final solution was to set the dataVariance on most of my > > objects to DYNAMIC, and then to delete the viewer explicitly _before_ > > deleting the data for any of those objects that were STATIC to > > guarantee that all of the previous rendering loops had finished and it > > was safe to do this. > > > > Out of curiosity, in general, when is it otherwise safe to > > modify/remove/add things to a STATIC node? i.e., if the Viewer's loop > > could be running at pretty much any time, is the only way to set > > dataVariance to DYNAMIC, wait a few frames, and then make the changes? > > > > Cheers, > > Adam > > > > On 9/15/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > > Hi Adam, > > > > > > Paul did a nice explanation so I have little to add. For future > > > reference what was the change that fixed the problem you were seeing? > > > > > > Robert. > > > > > > On 9/15/07, Adam Coates <[EMAIL PROTECTED]> wrote: > > > > Excellent - that was all the explanation I needed. Everything is > > > > humming along just fine now. > > > > > > > > Thanks, Paul! > > > > > > > > AC > > > > > > > > On 9/14/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > > > I'm not sure why you have a thread hung in drawImplementation() after > > > > > Viewer's destructor has been called. But I can explain some of the > > > > > other > > > > > stuff you have questions on, and hopefully that'll help. > > > > > > > > > > > My question is, how do you guys > > > > > > normally deal with data (scene graph, geometry, text, > > > > > > whatever) being modified on the main thread while Viewer is > > > > > > apparently busy rendering the same data? > > > > > > > > > > Mark the Node or Drawable as DYNAMIC DataVariance, and only modify it > > > > > during > > > > > the update traversal (or outside the rendering traversals). > > > > > > > > > > > Having looked at a lot of the other drawables included in > > > > > > OSG, I don't see how the "double buffering" scheme works -- > > > > > > how is that any of the scene graph or other geometry data get > > > > > > updated without creating a race condition like this? > > > > > > > > > > OSG operates on a gentleman's agreement under which you can do > > > > > whatever you > > > > > want to DYNAMIC nodes during the update traversal, and OSG's possibly > > > > > multiple threads can perform read-only operations during the cull/draw > > > > > traversals. > > > > > > > > > > With osgViewer-based apps, marking nodes that you intend to modify as > > > > > DYNAMIC is critical, otherwise OSG might let the update traversal > > > > > start (or > > > > > return from frame()) before it has finished processing the node that > > > > > you're > > > > > going to modify. > > > > > > > > > > > What's the trick here? What > > > > > > can/can't one do from with the drawImplementation() method in > > > > > > order to remain thread safe? > > > > > > > > > > drawImplementation() should be const, so as long as you don't modify > > > > > it or > > > > > anything else in the scene graph, you should be OK. > > > > > > > > > > Hope that helps. > > > > > > > > > > Paul Martz > > > > > Skew Matrix Software LLC > > > > > http://www.skew-matrix.com > > > > > 303 859 9466 > > > > > > > > > > _______________________________________________ > > > > > osg-users mailing list > > > > > [email protected] > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > > > _______________________________________________ > > > > osg-users mailing list > > > > [email protected] > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > _______________________________________________ > > > osg-users mailing list > > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
