Hi Doug,
On Tue, Nov 10, 2009 at 3:00 PM, Doug McCorkle <mc...@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.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
