Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Mon, Nov 9, 2009 at 5:54 PM, Doug McCorkle mc...@iastate.edu wrote: Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. There is nothing stopping you from using the VR juggler configuration to set the osgViewer Camera slaves up, osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 2:51 AM, Robert Osfield wrote: Hi Doug, On Mon, Nov 9, 2009 at 5:54 PM, Doug McCorkle mc...@iastate.edu wrote: Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. There is nothing stopping you from using the VR juggler configuration to set the osgViewer Camera slaves up, Correct, this would be just like how Performer is handled in VR Juggler. We have looked at this off and on over the past ~2 years and there does not seem to be much upside for all the work this would require. osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle mc...@iastate.edu wrote: osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. With the next rev of the OSG osgViewer will support both OpenGL 3.x, OpenGL ES 1.1 and OpenGL ES 2.0, if VR Juggler supported osgViewer with it's native windowing support then you'd get all this for free. Without using osgViewer you'd need to implement your own windowing support for these. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I don't thinking using window inheritance would require much more OSG/VRJuggler glue code than you presently have, it just be different code. Window inheritance would leave the OSG able to create the GL3 and GLES contexts as well, so you'd get these features for free :-) I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Once of the goals of GraphicsWindowEmedded is to provide similar support to that of using SceneView directly, if you aren't able to use it in this role then it's something I need to look at. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 8:42 AM, Robert Osfield wrote: Hi Doug, On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle mc...@iastate.edu wrote: osgViewer can happily be an implementation detail if VR juggler is flexible enough to not force it's own window creation. Correct, but again, that would assume that the OSG windowing implementation is better than what we already have. My personal opinion is that the windowing implementation in VR Juggler is better but we can disagree on this point. With the next rev of the OSG osgViewer will support both OpenGL 3.x, OpenGL ES 1.1 and OpenGL ES 2.0, if VR Juggler supported osgViewer with it's native windowing support then you'd get all this for free. Without using osgViewer you'd need to implement your own windowing support for these. We had OGL 3 context creation in VR Juggler last March. But... it rather does hobble the OSG in the way you are present using the OSG. You don't get access to the more sophisticated threading models, RTT support, DatabasePager you have wire up yourself... You are assuming we do not already have these tools RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. I believe you can do all this with using osgViewer and you'll get more out of the OSG as well. If you want to do windowing yourself then the ideal tool would be to create the windows and then using GraphicsWindow's ability to inherit the parent window to use. Your comment above is the best option in my opinion but would require OSG to become a compile time dependency of VR Juggler. Right now OSG is included in 1 file of VR Juggler which makes VR Juggler very portable. I don't thinking using window inheritance would require much more OSG/VRJuggler glue code than you presently have, it just be different code. Window inheritance would leave the OSG able to create the GL3 and GLES contexts as well, so you'd get these features for free :-) Very true but I am willing to pay the price to use a different windowing API. Again, just another personal preference we can disagree on. I think another good option would be to figure out how to make GraphicsWindowEmbedded work with multiple contexts. If we did this then we would have a direct SceneView replacement where all SceneView apps could easily migrate to osgViewer. Once of the goals of GraphicsWindowEmedded is to provide similar support to that of using SceneView directly, if you aren't able to use it in this role then it's something I need to look at. I was incorrect in my statement above. I can create an osgViewer for every context which would be equivalent to creating an SceneView for every context. I got some threads crossed in my mind. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle mc...@iastate.edu wrote: We had OGL 3 context creation in VR Juggler last March. Cool, what platforms do you have this support? Perhaps we can learn a little about adding it to osgViewer :-) RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. You'll be limited to just using FBO's or frame buffer copies though. One of the things I've striven for with osg::Camera and it's RTT support is that it can handle using a range of different back end implementations, including Pbuffers which are the fallback for drivers that don't have FBOs. osgViewer provides the ability for RTT Camera's to create Pbuffers if and when they need them. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? The reasons why it matters to me are: 1) I just want the OSG to shine as best it can without any limitations 2) I want the OSG users to be able to reuse as much expertise as possible - so they can learn from OSG examples, tutorials and discussions on osg-users. The more differences there are in usage the less this is possible. 3) I want to be able to roll out new features to all users, so they all get to benefit quickly and without breaking existing apps. The lower level users dive in setting up the OSG the more difficult it is to avoid breaking things and the longer it'll take them to take advantage of them. 4) Get more users using and therefore testing the same code paths so that we can improve the quality of the OSG. 5) Avoid having to support users with obscure problems that I can't recreate myself because they have their own way of doing windowing threading. If I can recreate problems myself then it become very difficult to do support. Hence my desire to sheppard users into using API's that unify OSG usage, and if we get the OSG API's right then this needn't come with any compromises for end users application, rather the opposite, if we get it right it's a win-win, I get any easier life, and you get more features and more reliable software in an easier to use package. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 10, 2009, at 10:31 AM, Robert Osfield wrote: Hi Doug, On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle mc...@iastate.edu wrote: We had OGL 3 context creation in VR Juggler last March. Cool, what platforms do you have this support? We have windows and X. Cocoa is waiting until Apple gets their act together. Perhaps we can learn a little about adding it to osgViewer :-) You already are, you have Paul Martz doing the port and Todd Furlong is an active member of the community as well. RTT support in the OSG relies upon the ability to create on FBO and PBuffers on demand, unless you've implemented your own integration of PBuffers with the OSG then you'll be missing this capability. No we have not and I can create an RTT camera without osgViewer. You'll be limited to just using FBO's or frame buffer copies though. Correct, but again this is my choice as a developer. One of the things I've striven for with osg::Camera and it's RTT support is that it can handle using a range of different back end implementations, including Pbuffers which are the fallback for drivers that don't have FBOs. osgViewer provides the ability for RTT Camera's to create Pbuffers if and when they need them. Right but because OSG is flexible I can make this choice as a developer. Window inheritance is still far more flexible and powerful w.r.t OSG capabilities so this is the route I'd recommend. SceneView and GraphicsWindowEmbedded on their own hobble the OSG. But this is your opinion that they are hobbling OSG. For folks like me and I am sure some others in the OSG community both of these interfaces provide a slick and easy way to get a majority of the OSG support that they need with another software API. This enables the OSG community to be larger and more active than without these interfaces in place. I think this is one of the great things about the OSG. I can grab as much or as little of the OSG as I need too. If I as a developer am willing to give up some functionality in the OSG in using these interfaces why should that matter? The reasons why it matters to me are: 1) I just want the OSG to shine as best it can without any limitations 2) I want the OSG users to be able to reuse as much expertise as possible - so they can learn from OSG examples, tutorials and discussions on osg-users. The more differences there are in usage the less this is possible. 3) I want to be able to roll out new features to all users, so they all get to benefit quickly and without breaking existing apps. The lower level users dive in setting up the OSG the more difficult it is to avoid breaking things and the longer it'll take them to take advantage of them. This is a choice a developer can make knowing the disadvantages to it. The OSG should not force a specific usage type. Again, in my case, I am willing to put up with this extra work to take advantage of some other toolkits. 4) Get more users using and therefore testing the same code paths so that we can improve the quality of the OSG. 5) Avoid having to support users with obscure problems that I can't recreate myself because they have their own way of doing windowing threading. If I can recreate problems myself then it become very difficult to do support. In this case, I and am guessing others have other support methods which work well. Hence my desire to sheppard users into using API's that unify OSG usage, and if we get the OSG API's right then this needn't come with any compromises for end users application, rather the opposite, if we get it right it's a win-win, I get any easier life, and you get more features and more reliable software in an easier to use package. Those are all great goals for the OSG. As a developer for my application I only need the core functionality of OSG therefore by maintaining an interface that provides access to the core OSG we all can move forward. That is all that I request. Keep an interface available that provides easy access into core OSG. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the help. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Doug McCorkle wrote: Hello Robert, After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? My understanding is that you create your own window and context, and make them current, then call setUpViewerAsEmbeddedInWindow. (Honestly, I'm not cure why osgViewer needs the window size passed as params; it seems like osgViewer could just query them from the window system. Maybe Robert can elaborate?) Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? So, for example, your app opens multiple windows, each with their own context, say for a tiled display or CAVE... You only have one View (with multiple slave cameras) so it seems like this should work. Robert? Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? This is a good question. Under the embedded model, you own context management, so the osgViewer threading models don't come in to play. I think the answer is that you use one thread to call Viewer::updateTraversal, and then you fire off concurrent threads to execute Viewer::renderingTraversals. Basically, you need to look at the internals of frame() to see what you need to do. (Keep in mind that Viewer derives from ViewerBase, so be sure to look at both classes for relevant code). I do not see a way to separate these two operations with the examples provided that use the frame call. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); are these same calls made on the osgViewer camera just like in SceneView? Pretty much, yes. Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the help. I don't think osgViewer would be able to hide it; you can search the source code to see what it does. I don't think you have a need to push and pop the matrix stack around your draw, unless you have code outside of cull and draw that depends on the matrices being set a certain way. I hope this helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug and Paul, On Mon, Nov 9, 2009 at 5:09 PM, Paul Martz pma...@skew-matrix.com wrote: My understanding is that you create your own window and context, and make them current, then call setUpViewerAsEmbeddedInWindow. (Honestly, I'm not cure why osgViewer needs the window size passed as params; it seems like osgViewer could just query them from the window system. Maybe Robert can elaborate?) The whole point of GraphicsWindowEmbedded is to hide the windowing system support entirely from osgViewer, so it doesn't have any way what so ever to query anything about the windowing system. Just like SceneView you have to tell it the size of viewport/window etc. Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? So, for example, your app opens multiple windows, each with their own context, say for a tiled display or CAVE... You only have one View (with multiple slave cameras) so it seems like this should work. Robert? GraphicsWindowsEmbedded is suited for single context, single threaded apps. If you want to multi-context apps then the way to do is to use window inheritance feature of osgViewer::GraphicsWindow and inherit your applications generated window. The osgviewerMFC and osgviewerWx are examples that use GraphicsWindow inheritance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Mon, Nov 9, 2009 at 3:52 PM, Doug McCorkle mc...@iastate.edu wrote: After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? One of the limits of GrapicsWindowEmbedded is that it can't automatically handle multi-threaded, multi-context usage. You potentially could have multipe osgViewer::Viewer each with it's own GraphicsWindowEmbedded, and set the ContextID for each GraphicsWindowEmbedded by getting the doing graphicswindow-getState()-setContextID(i);. However, for multi-context work you really are better off using osgViewer::GraphicsWindow window inheritance. Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. You can break viewer.frame() down into it' update and rendering dispatch components. If you use GraphicsWindow inheritance, or native GraphicsWindow generation you'll actually get all the threading you are already doing for free. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); Not much different: viewer.getCamera()-setViewport(..); viewer.getCamera()-seProjectionMatrix(..); viewer.getCamera()-seViewMatrix(..); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the You could wrap this all around the viewer.renderingTraversals(); call if you want. It's pretty hacky though doing all the push and pops. OpenGL 3.x and OpenGL ES 2.0 don't support such hacks so the days are numbered for this type of approach. -- I have to ask, what is the compelling reason to not to use osgViewer and role you own? It does multi-thread, multi-context natively - it can do caves, power-walls and much more (such as distortion correction), it just a matter of configuring the viewer with the appropriate slave Cameras. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 9, 2009, at 11:41 AM, Robert Osfield wrote: Hi Doug, On Mon, Nov 9, 2009 at 3:52 PM, Doug McCorkle mc...@iastate.edu wrote: After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? One of the limits of GrapicsWindowEmbedded is that it can't automatically handle multi-threaded, multi-context usage. You potentially could have multipe osgViewer::Viewer each with it's own GraphicsWindowEmbedded, and set the ContextID for each GraphicsWindowEmbedded by getting the doing graphicswindow-getState()-setContextID(i);. Slick. So this would be very similar to what we are doing now with SceneView. Thanks for the insight. However, for multi-context work you really are better off using osgViewer::GraphicsWindow window inheritance. Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. You can break viewer.frame() down into it' update and rendering dispatch components. Thanks. I will look into this. If you use GraphicsWindow inheritance, or native GraphicsWindow generation you'll actually get all the threading you are already doing for free. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); Not much different: viewer.getCamera()-setViewport(..); viewer.getCamera()-seProjectionMatrix(..); viewer.getCamera()-seViewMatrix(..); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the You could wrap this all around the viewer.renderingTraversals(); call if you want. It's pretty hacky though doing all the push and pops. OpenGL 3.x and OpenGL ES 2.0 don't support such hacks so the days are numbered for this type of approach. Yup. This will be disappearing in our app very soon with our OGL 3 migration this spring. -- I have to ask, what is the compelling reason to not to use osgViewer and role you own? It does multi-thread, multi-context natively - it can do caves, power-walls and much more (such as distortion correction), it just a matter of configuring the viewer with the appropriate slave Cameras. Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. Thanks again for the pointers above. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
