[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
mccdo at iastate.edu
Tue Nov 10 09:24:11 PST 2009
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>
>> 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
> 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
>>> 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
> 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
> 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
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.
More information about the osg-users