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

Doug McCorkle mccdo at iastate.edu
Tue Nov 10 09:24:11 PST 2009


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 <mccdo at 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



More information about the osg-users mailing list