[osg-users] OSG, VR Juggler, and multiple render threads...
Hello, We are using SceneView from OSG 1.2 and VR Juggler in a multiple render thread environment. We are using the osgUtil::UpdateVisitor to update the graph in a serial portion of our code. SceneView::cull and SceneView::draw are called from each rendering thread. In this configuration we often see the displays flash the clear color on a random basis. We are setting the clear color through the use of a ClearNode and we clear the depth buffer at the beginning of the draw function. The "flashing" of the clear color is not seen when only one render thread is utilized. Is there a reason we are be seeing this behavior? Are we mismanaging something in our draw loop? Thanks for the help. Doug PS. Initial testing has shown this to occur under the OSG 1.9.x series as well. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
Hi Doug, There are number of hoops one has to jump through to do safe multi-threading with the OSG, osgViewer does these all for you, while SceneView knows nothing of it and requires higher level classes to handle it. osgViewer itself does use SceneView so does illustrate that it is possible using SceneView so you could possible use this as guide. Personally I'd recommend that VRJuggler just use osgViewer for creating the windows and cameras as per the configuration required by VRJuggler, this way you can take advantage of all the threading models that osgViewer provides in a way that is known to be thread safe. Another key advantage of adopting osgViewer is that problems you see will be much more reproducible by others who don't use VRJuggler. For instance you could create a scene that uses a ClearNode and run in standard OSG examples, and if the problems exists then I and others can look into it. With the current state of play, trying to help diagnose what might be up would require a massive time investment in getting VR Juggler installed, learning about it, setting up the case that reproduces the problem, then stepping through to see where the problem lies. The alterntaive of trying to debug this stuff remotely with even knowing all the VRJuggler code is no mean feat either - there are many things that VR Juggler could be doing wrong w.r.t multi-threaded set up of the OSG, or it could a problem on the OSG side. Trying to sort it out this way would again require a huge investment of time all round. I'm afraid I'm certainly too over stretched to undertake such a process. One of osgViewer core goals is making multi-thread, multi-channel usage of the OSG straight forward, hiding all the subtle details and thread synchronization that is required. I'm not familiar with VR Juggler, but I would have though it should possible to replace the existing SceneView framework with a osgViewer::Viewer object and have the Viewer's windows and cameras all set up according to VR Juggler configuration. Robert. On 8/2/07, Doug McCorkle <[EMAIL PROTECTED]> wrote: > Hello, > We are using SceneView from OSG 1.2 and VR Juggler in a > multiple render thread environment. We are using the > osgUtil::UpdateVisitor to update the graph in a serial portion of our > code. SceneView::cull and SceneView::draw are called from each > rendering thread. In this configuration we often see the displays > flash the clear color on a random basis. We are setting the clear > color through the use of a ClearNode and we clear the depth buffer at > the beginning of the draw function. The "flashing" of the clear color > is not seen when only one render thread is utilized. Is there a > reason we are be seeing this behavior? Are we mismanaging something > in our draw loop? Thanks for the help. > > Doug > > PS. Initial testing has shown this to occur under the OSG 1.9.x > series as well. > > ___ > 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] OSG, VR Juggler, and multiple render threads...
> We are using SceneView from OSG 1.2 and VR Juggler in a > multiple render thread environment. We are using the > osgUtil::UpdateVisitor to update the graph in a serial > portion of our code. SceneView::cull and SceneView::draw are > called from each rendering thread. In this configuration we > often see the displays flash the clear color on a random > basis. We are setting the clear color through the use of a > ClearNode and we clear the depth buffer at the beginning of > the draw function. Hi Doug -- Just thinking of this in OpenGL terms, the dreaded "blank screen" can have many many causes. One possible explanation: The cull traversal on one of the displays randomly thinks that everything is culled. This could be due to a configuration issue for the camera controlling that display, the modelview/projection matrices are bogus and/or the view volume used during the cull traversal isn't set correctly. You might consider hacking the code to dump such information out per frame. Yes, it will generate gobs of output, but if you do a short run and see a flash, then examine the debug output, any one-frame irregularities should jump out at you. If nothing shows up, then the problem is somewhere else. The other thought I had relates to the ClearNode. Does the problem go away if you eliminate the ClearNode and just let SceneView do its own clearing? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On Aug 3, 2007, at 10:47 AM, Paul Martz wrote: >> We are using SceneView from OSG 1.2 and VR Juggler in a >> multiple render thread environment. We are using the >> osgUtil::UpdateVisitor to update the graph in a serial >> portion of our code. SceneView::cull and SceneView::draw are >> called from each rendering thread. In this configuration we >> often see the displays flash the clear color on a random >> basis. We are setting the clear color through the use of a >> ClearNode and we clear the depth buffer at the beginning of >> the draw function. > > Hi Doug -- Just thinking of this in OpenGL terms, the dreaded > "blank screen" > can have many many causes. > > One possible explanation: The cull traversal on one of the displays > randomly > thinks that everything is culled. This could be due to a > configuration issue > for the camera controlling that display, the modelview/projection > matrices > are bogus and/or the view volume used during the cull traversal > isn't set > correctly. You might consider hacking the code to dump such > information out > per frame. Yes, it will generate gobs of output, but if you do a > short run > and see a flash, then examine the debug output, any one-frame > irregularities > should jump out at you. If nothing shows up, then the problem is > somewhere > else. > I will give this a shot. > The other thought I had relates to the ClearNode. Does the problem > go away > if you eliminate the ClearNode and just let SceneView do its own > clearing? > As far as we can tell SceneView does not do clearing or not that we can find. Am I incorrect here? I have never really been able to figure out how to get reliable clearing with SceneView. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On 8/3/07, Doug McCorkle <[EMAIL PROTECTED]> wrote: > As far as we can tell SceneView does not do clearing or not that we > can find. Am I incorrect here? I have never really been able to > figure out how to get reliable clearing with SceneView. We'll its RenderStage that SceneView uses to clear, and its ClearNode that just adjusts the default settings of the clear that RenderStage does and done from with the cull traversal. In effect it'll be exactly the same code doing the clear, the only difference is that how the values are set - one from the defaults provided by SceneView, and one from the scene graph. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
> We'll its RenderStage that SceneView uses to clear, and its > ClearNode that just adjusts the default settings of the clear > that RenderStage does and done from with the cull traversal. > In effect it'll be exactly the same code doing the clear, the > only difference is that how the values are set - one from the > defaults provided by SceneView, and one from the scene graph. Ah! Thanks. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
hi doug, lots of good ideas in the thread so far. my gut feeling is similar to yours, that it is a threading thing, but it's hard to diagnose from a distance. :) one thing you could do is expressly set each channel's clear color differently, to try to see if state is leaking from one context to another. so, set one to red, another blue, another green, and see if when you see the flash, that maybe the color might inidicate which (or if) another context's state is leaking. if so, it implies some sort of thread confusion, that for a moment, one set of state is being applied in the wrong context. other than that, you could try logging clears from the clearnodes, or running through a debugger to see what happens in each thread wrt what gl calls are issued, and when. you should be able to see a context made current, and a set of initial state happen (including clear color, if you've got a clearnode), and then the actual clear. the mac opengl debugger makes this sort of process relatively easy. anyway, just a few thoughts for a hot friday afternoon. good luck! bob bob kuehne founder and ceo - blue newt software, llc [EMAIL PROTECTED] - 734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
>> We are using SceneView from OSG 1.2 and VR Juggler in a >> multiple render thread environment. We are using the >> osgUtil::UpdateVisitor to update the graph in a serial >> portion of our code. SceneView::cull and SceneView::draw are >> called from each rendering thread. In this configuration we >> often see the displays flash the clear color on a random >> basis. We are setting the clear color through the use of a >> ClearNode and we clear the depth buffer at the beginning of >> the draw function. > > Hi Doug -- Just thinking of this in OpenGL terms, the dreaded "blank > screen" > can have many many causes. > > One possible explanation: The cull traversal on one of the displays > randomly > thinks that everything is culled. This could be due to a configuration > issue > for the camera controlling that display, the modelview/projection matrices > are bogus and/or the view volume used during the cull traversal isn't set > correctly. You might consider hacking the code to dump such information > out > per frame. Yes, it will generate gobs of output, but if you do a short run > and see a flash, then examine the debug output, any one-frame > irregularities > should jump out at you. If nothing shows up, then the problem is somewhere > else. > If I make the SceneView::cull call guarded with a mutex then the problem goes away. I printed out the frustum values and view matrix and nothing seemed to be wrong there. Any ideas on what might not be thread safe in cull or what I may be doing wrong with my management of cull settings? Also, this code is not using anything special in terms of hardware occlusion culling or the small feature culling. > The other thought I had relates to the ClearNode. Does the problem go away > if you eliminate the ClearNode and just let SceneView do its own clearing? >-Paul > Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
>>> We are using SceneView from OSG 1.2 and VR Juggler in a >>> multiple render thread environment. We are using the >>> osgUtil::UpdateVisitor to update the graph in a serial >>> portion of our code. SceneView::cull and SceneView::draw are >>> called from each rendering thread. In this configuration we >>> often see the displays flash the clear color on a random >>> basis. We are setting the clear color through the use of a >>> ClearNode and we clear the depth buffer at the beginning of >>> the draw function. >> >> Hi Doug -- Just thinking of this in OpenGL terms, the dreaded "blank >> screen" >> can have many many causes. >> >> One possible explanation: The cull traversal on one of the displays >> randomly >> thinks that everything is culled. This could be due to a configuration >> issue >> for the camera controlling that display, the modelview/projection >> matrices >> are bogus and/or the view volume used during the cull traversal isn't >> set >> correctly. You might consider hacking the code to dump such information >> out >> per frame. Yes, it will generate gobs of output, but if you do a short >> run >> and see a flash, then examine the debug output, any one-frame >> irregularities >> should jump out at you. If nothing shows up, then the problem is >> somewhere >> else. >> > If I make the SceneView::cull call guarded with a mutex then the problem > goes away. I printed out the frustum values and view matrix and nothing > seemed to be wrong there. Any ideas on what might not be thread safe in > cull or what I may be doing wrong with my management of cull settings? > Also, this code is not using anything special in terms of hardware > occlusion culling or the small feature culling. > >> The other thought I had relates to the ClearNode. Does the problem go >> away >> if you eliminate the ClearNode and just let SceneView do its own >> clearing? >>-Paul >> What does this particular changeset address: http://www.openscenegraph.org/projects/osg/changeset/7177 Does it address anything in relation to this thread? Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On 8/7/07, Doug McCorkle <[EMAIL PROTECTED]> wrote: > What does this particular changeset address: > > http://www.openscenegraph.org/projects/osg/changeset/7177 Well its says at the top "Added save and restoring of the cull mask to Camera handling code" > Does it address anything in relation to this thread? No afraid not. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On Aug 7, 2007, at 7:49 AM, Robert Osfield wrote: > On 8/7/07, Doug McCorkle <[EMAIL PROTECTED]> wrote: >> What does this particular changeset address: >> >> http://www.openscenegraph.org/projects/osg/changeset/7177 > > Well its says at the top "Added save and restoring of the cull mask to > Camera handling code" > Right. I did not understand what that meant. >> Does it address anything in relation to this thread? > > No afraid not. OK. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
>>> We are using SceneView from OSG 1.2 and VR Juggler in a >>> multiple render thread environment. We are using the >>> osgUtil::UpdateVisitor to update the graph in a serial >>> portion of our code. SceneView::cull and SceneView::draw are >>> called from each rendering thread. In this configuration we >>> often see the displays flash the clear color on a random >>> basis. We are setting the clear color through the use of a >>> ClearNode and we clear the depth buffer at the beginning of >>> the draw function. >> >> Hi Doug -- Just thinking of this in OpenGL terms, the dreaded "blank >> screen" >> can have many many causes. >> >> One possible explanation: The cull traversal on one of the displays >> randomly >> thinks that everything is culled. This could be due to a configuration >> issue >> for the camera controlling that display, the modelview/projection >> matrices >> are bogus and/or the view volume used during the cull traversal isn't >> set >> correctly. You might consider hacking the code to dump such information >> out >> per frame. Yes, it will generate gobs of output, but if you do a short >> run >> and see a flash, then examine the debug output, any one-frame >> irregularities >> should jump out at you. If nothing shows up, then the problem is >> somewhere >> else. >> > If I make the SceneView::cull call guarded with a mutex then the problem > goes away. I printed out the frustum values and view matrix and nothing > seemed to be wrong there. Any ideas on what might not be thread safe in > cull or what I may be doing wrong with my management of cull settings? > Also, this code is not using anything special in terms of hardware > occlusion culling or the small feature culling. > >> The other thought I had relates to the ClearNode. Does the problem go >> away >> if you eliminate the ClearNode and just let SceneView do its own >> clearing? >>-Paul >> I am still seeing these problems with the osg HEAD as well. Any more suggestions on things to try or look into? Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On 8/3/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > Hi Doug, > > There are number of hoops one has to jump through to do safe > multi-threading with the OSG, osgViewer does these all for you, while > SceneView knows nothing of it and requires higher level classes to > handle it. osgViewer itself does use SceneView so does illustrate > that it is possible using SceneView so you could possible use this as > guide. > > Personally I'd recommend that VRJuggler just use osgViewer for > creating the windows and cameras as per the configuration required by > VRJuggler, this way you can take advantage of all the threading models > that osgViewer provides in a way that is known to be thread safe. > > Another key advantage of adopting osgViewer is that problems you see > will be much more reproducible by others who don't use VRJuggler. > For instance you could create a scene that uses a ClearNode and run in > standard OSG examples, and if the problems exists then I and others > can look into it. > > With the current state of play, trying to help diagnose what might be > up would require a massive time investment in getting VR Juggler > installed, learning about it, setting up the case that reproduces the > problem, then stepping through to see where the problem lies. Actually, all the OSG code for VR Juggler is contained in one header file: http://developer.vrjuggler.org/browser/juggler/branches/2.2/modules/vrjuggler/vrj/Draw/OSG/OsgApp.h Could you give this file the once over and alert us to any problems? If you have any questions I can certainly try to explain what is going on. -- Daniel E. Shipton Software Engineer, Infiscape Corp. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG, VR Juggler, and multiple render threads...
On Aug 7, 2007, at 7:26 PM, Daniel E. Shipton wrote: > On 8/3/07, Robert Osfield <[EMAIL PROTECTED]> wrote: >> Hi Doug, >> >> There are number of hoops one has to jump through to do safe >> multi-threading with the OSG, osgViewer does these all for you, while >> SceneView knows nothing of it and requires higher level classes to >> handle it. osgViewer itself does use SceneView so does illustrate >> that it is possible using SceneView so you could possible use this as >> guide. >> >> Personally I'd recommend that VRJuggler just use osgViewer for >> creating the windows and cameras as per the configuration required by >> VRJuggler, this way you can take advantage of all the threading >> models >> that osgViewer provides in a way that is known to be thread safe. >> >> Another key advantage of adopting osgViewer is that problems you see >> will be much more reproducible by others who don't use VRJuggler. >> For instance you could create a scene that uses a ClearNode and >> run in >> standard OSG examples, and if the problems exists then I and others >> can look into it. >> >> With the current state of play, trying to help diagnose what might be >> up would require a massive time investment in getting VR Juggler >> installed, learning about it, setting up the case that reproduces the >> problem, then stepping through to see where the problem lies. > > Actually, all the OSG code for VR Juggler is contained in one > header file: > http://developer.vrjuggler.org/browser/juggler/branches/2.2/modules/ > vrjuggler/vrj/Draw/OSG/OsgApp.h > > Could you give this file the once over and alert us to any problems? > If you have any questions I can certainly try to explain what is going > on. We were able to fix this by calling getBound after using the UpdateVisitor on the root node of the scenegraph. There is a note in SceneView::update on why this needs to be done in this manner. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
