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

Reply via email to