[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes

Robert Osfield robert.osfield at gmail.com
Tue Nov 10 08:31:33 PST 2009

Hi Doug,

On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle <mccdo at 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.


More information about the osg-users mailing list