HI Bruce, You can create a subclass from osg::Drawable, or use Drawable draw callback, or use a Camera pre/post draw callback to do your own OpenGL work. When doing this you'll need to make sure that the OSG knows about the state you have changed so it can correctly manage state - this is is crucial as the OSG does lazy state updating to reduce the number of OpenGL calls, and if you change OpenGL state without telling it then it'll just out of sync and won't apply the state when it needs to. osg::State object has a number of haveApplied*() methods for telling it that you've changed state.
Personally I would suggest that that the native OSG is actually the best way to tackle your problem. The OSG has support for textures including PBO's and texture subloading, it also has support for GLSL shaders, so everything you want to do is very straight forward to do using native OSG classes. Yes it does mean learning about them, but it'll be a lot easier and loss problematic than learning about creating your callback and informing the osg::State state tracking about your state changes. Robert. On Thu, Apr 1, 2010 at 1:48 AM, Bruce Wheaton <[email protected]> wrote: > I'm moving my backend to OSG, but I'm too chicken to do it all at once. > Where would be the best place to run existing code? > > The code is a set of texture transfers (individual planes of videos) and > then some drawing with a shader to convert it to floating point RGB. > > The transfer code should: > > run every single frame, before other operations (resulting textures get > used), > should ideally be split - transfer starts (PBOs) and transfer completion, > could optionally use a pre-process camera and osg::uniforms, > Can be overlapped with existing rendering (the tail of the previous drawing) > - first phase won't affect textures in use. > Should be done once per GPU (assuming contexts are shared on each card). > > Is there a callback or two that would fit? Is it kosher to do the work in a > draw callback, or is there an earlier point that is in the OpenGL context? > Maybe an example? > > Since I know the 'best advice' will probably be to bite the bullet, as a > sanity check, I mention that my code is an ffmpeg video channel that decodes > the video into native planes, then transfers multiple planes and uses a > shader and multiple texturing to convert to floating point and do various > color correction etc. I think fitting that into the existing ImageSequence, > which seems to assume single frames of RGB, would be too time consuming at > the moment. > > Regards, > > Bruce Wheaton > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
