Hi Raphael,
On 17/08/09 2:10 PM, Raphael Sebbe wrote:
To further clarify, my goal is to be able to use multiple GL contexts
representing the same scene from different camera angles, and those contexts
could well be GL views in windows, FBOs, or even Core Animation GL layers
(Mac). As said previously, having textures on 3D objects being the result of
some GPU image processing (Core Image), or the other way around, using the
result of 3D rendering as input to GPU filters (Core Image) are possible
applications. But all these things require some kind of flexibility in the
way you create/declare (possibly shared) contexts, to avoid duplicating VBO,
DL and other GPU resources all over.
A nice extension to OSG would be to make it possible to work with external
contexts, even if some constraints need to be enforced (such as state
preserving across OSG calls, or other threading constraints). But this is
probably easier to say than to implement. I will dig some more in the source
to find out.
I would also find this a helpful extension.
A while ago I wrote some code to that effect for passing an AGLContext* as
traits->sharedContext to GraphicsWindowCarbon. The code would first do the usual
dynamic_cast to GraphicsWindowCarbon and PixelBufferCarbon and if both fail would simply
static_cast the pointer to AGLContext.
This was an ugly hack of course. A better(?) way might be to create a
GraphicsWindowCarbon constructor with an existing AGLContext*.
Cheers,
/ulrich
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
