share SDL OpenGL context, create offscreen rendering context

[Ulrich Hertlein]

Hi all,

does anybody know if it's possible to create an osg::GraphicsContext that's sharing an
existing OpenGL context (created by SDL, i.e. not wrapped in another GraphicsContext)?

What I'm trying to solve is:
- SDL creates an OpenGL context
- create an osgViewer that's sharing the SDL OpenGL context (pass the context pointer as
traits->sharedContext?)
- the OSG context should be off-screen if possible
- OSG would then render a FBO camera to an attached texture and the texture ID could
be used in SDL to display the result
- the point is to avoid OGL state conflicts between the existing app and OSG

Any comments, ideas, etc. are welcome.

Cheers,
/ulrich

[Robert Osfield]

Hi Ulrich,

You'd need to be able to get access to the GLX/GLW etc handle for the
context to be able to do this, something I think that SDL probably
hides.

For this type of work you really should not use SDL, it really isn't
and API that scales well to handling things like threading or
multi-context work. The inbuilt features of osgViewer are much better
for doing this, SDL offers nothing extra - only restrictives relative
to what the inbuilt window support can provide.

The only reason to use SDL in the context of the OSG is for doing
device handling such as joysticks or basic audio.

Robert.

Post by Ulrich Hertlein
Hi all,
does anybody know if it's possible to create an osg::GraphicsContext that's
sharing an existing OpenGL context (created by SDL, i.e. not wrapped in
another GraphicsContext)?
- SDL creates an OpenGL context
- create an osgViewer that's sharing the SDL OpenGL context (pass the
context pointer as traits->sharedContext?)
- the OSG context should be off-screen if possible
- OSG would then render a FBO camera to an attached texture and the texture ID could
 be used in SDL to display the result
- the point is to avoid OGL state conflicts between the existing app and OSG
Any comments, ideas, etc. are welcome.
Cheers,
/ulrich
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Ulrich Hertlein]

Hi Robert,

Post by Robert Osfield
You'd need to be able to get access to the GLX/GLW etc handle for the
context to be able to do this, something I think that SDL probably
hides.

Indeed it does. I was hoping to use the various *GetCurrentContext() functions available
on Carbon, Unix, and Windows.

Post by Robert Osfield
For this type of work you really should not use SDL, it really isn't
and API that scales well to handling things like threading or
multi-context work. The inbuilt features of osgViewer are much better
for doing this, SDL offers nothing extra - only restrictives relative
to what the inbuilt window support can provide.

I hear you :-)
But this is for an existing framework/API that otherwise wouldn't have a dependency on OSG
and there probably would be a few unhappy people if I suddenly introduce a new dependency
as complex as OSG 'just' for the windowing...

Post by Robert Osfield

Post by Ulrich Hertlein
- create an osgViewer that's sharing the SDL OpenGL context (pass the
context pointer as traits->sharedContext?)
- the OSG context should be off-screen if possible
- OSG would then render a FBO camera to an attached texture and the texture ID could
be used in SDL to display the result
- the point is to avoid OGL state conflicts between the existing app and OSG

Cheers,
/ulrich

[Robert Osfield]

Hi Ulrich,

Post by Ulrich Hertlein
Hi Robert,
Indeed it does.  I was hoping to use the various *GetCurrentContext()
functions available on Carbon, Unix, and Windows.

You'll also need makeCurrent and releaseContext methods as well to be
able to multiple graphics context work. I don't recall SDL having
these - I looked for these when I wrote the osgviewersdl example but
couldn't implement a GaphicsWindowSDL purely because of these.

Basically SDL can't do multiple context work.

Post by Ulrich Hertlein

Post by Robert Osfield
For this type of work you really should not use SDL, it really isn't
and API that scales well to handling things like threading or
multi-context work.  The inbuilt features of osgViewer are much better
for doing this, SDL offers nothing extra - only restrictives relative
to what the inbuilt window support can provide.

I hear you :-)
But this is for an existing framework/API that otherwise wouldn't have a
dependency on OSG and there probably would be a few unhappy people if I
suddenly introduce a new dependency as complex as OSG 'just' for the
windowing...

We'll if you want advanced rendering support such as handling multiple
rendering contexts then SDL just won't cut the mustard, you'll have to
look to a more advanced toolkit.

The best you can do in your position is try to use the OSG's FBO
support at least then you could do everything from a single graphics
context.

Robert.

[Ulrich Hertlein]

Hi Robert,

Post by Robert Osfield
You'll also need makeCurrent and releaseContext methods as well to be
able to multiple graphics context work. I don't recall SDL having
these - I looked for these when I wrote the osgviewersdl example but
couldn't implement a GaphicsWindowSDL purely because of these.
Basically SDL can't do multiple context work.

Okay, but OSG can, right? So if SDL thinks it's only dealing with a single context and
OSG does the context work (make pbuffer context current, render, release) wouldn't that work?

Post by Robert Osfield
The best you can do in your position is try to use the OSG's FBO
support at least then you could do everything from a single graphics
context.

But OSG and SDL would still get in each others way w.r.t. OpenGL state handling.
I was (still am) hoping that I can get OSG to create and manage a separate context
alongside the SDL OpenGL context. Worst case the only linkage would be via glReadPixels
from the OSG context and uploading to another context.

Cheers,
/ulrich

[Robert Osfield]

Hi Ulrich,

Post by Robert Osfield
Basically SDL can't do multiple context work.

Okay, but OSG can, right?  So if SDL thinks it's only dealing with a single
context and OSG does the context work (make pbuffer context current, render,
release) wouldn't that work?

No. If you have a single thread you have to make one context current
do stuff, then release the context, then make the new context current,
do stuff, then release the second context, then make the first context
current again.

Post by Robert Osfield
The best you can do in your position is try to use the OSG's FBO
support at least then you could do everything from a single graphics
context.

But OSG and SDL would still get in each others way w.r.t. OpenGL state handling.

No. SDL doesn't do any OpenGL state work as far as I'm aware, it just
sets up the context and then your app does everything else.

I was (still am) hoping that I can get OSG to create and manage a separate
context alongside the SDL OpenGL context.  Worst case the only linkage would
be via glReadPixels from the OSG context and uploading to another context.

Man you're making this hard for yourself. Stop expecting SDL to be
your friend on this stuff. It's designed for simple OpenGL apps that
just need a single context and to run it single threaded - for this
it's great, go outside this scope and your on going to waste your time
and everybody elses.

Robert.

[Ulrich Hertlein]

Hi Robert,

sorry, I really didn't mean to pester you (or anybody else) with this stuff as much as I
did :-}

Yes, SDL has limitations with multi context apps. But since I'm plugging into existing
code I can't very well say: it's too hard/impossible, switch to osgViewer (or Producer or
whatever else does handle multi context apps properly).

Thanks for the advice, I guess we can put the topic to rest :-)

Cheers,
/ulrich