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
