Excellent, this is great info. Turns out the issue I'm currently running into is reproducible in v1.2, prior to the new threading models, and I'm not trying to access the context outside of cull/draw, so this means my problem must lie elsewhere and is not context-related.
This post from you will be good source material for the future OSG Programming Guide. :-) Again, thanks for the info. -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Tuesday, June 05, 2007 9:52 AM > To: osg users > Subject: Re: [osg-users] Access to current context > > Hi Paul, > > I'm not really sure what clarification you're after. With > the OSG, in principle you only ever have access to the > graphics context during the draw traversal, this doesn't > matter whether your using SceneView, osgProducer or osgViewer. > > Now, you can break this principle if you know that you have a > context current, but its not something I have ever > encouraged, and wouldn't do now. In the case of osgProducer > in 1.2 and even now the rendering is done from a thread that > call cull-draw in series, and as consequence cull will have > the context current. Also when users have used SceneView > typically the app is single threaded so again context is > current all the time, update, cull and draw. > > In osgViewer its more flexible, it can do : > > SingleThreaded - all traversals will have context current, > but the context will change > if you have multiple windows. > > CullDrawThreadPerContext - each context has a thread, > which call cull and draw in > series (a bit like Producer's ThreadPerCamera when one it > has one Camera or Context), > so you could in theory play fast and loose with do thread > ops in cull. > > DrawTheadPerContext - main thread does all camera culls, > draw threads are all > done in their own separate contexts. Its not safe to any > graphics calls in cull. > > CullThreadPerCameraDrawThreadPerContext - cull have > their own threads without > contexts current, draws are all done on the graphics > threads. Its not safe to any > graphics calls in cull. > > Robert. > > > > > > On 6/5/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > > > > > Hi Robert -- I'm running into an issue with my occlusion > query work, > > which again appears to be an incorrect assumption on my > part regarding > > when a rendering context is current. I don't recall seeing any > > documentation on this subject, so I was hoping you could > shed some light on it. > > > > It'd be very interesting to see a summary from you about > access to the > > current rendering context under osgProducer in v1.2, and > how that has > > now changed under osgViewer in v2.0. > > > > (I'm assuming for a SceneView-based app, that access to the current > > context is entirely under application control? Correct me if I'm > > wrong, been a while since I went down that path.) > > > > Thanks in advance for the clarification. > > > > Paul Martz > > Skew Matrix Software LLC > > http://www.skew-matrix.com > > 303 859 9466 > > > > _______________________________________________ > > osg-users mailing list > > osg-users@openscenegraph.net > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
