> The easist way would be to have the PEI VisKit OpenGL drawing code
> enclosed within a glPushAttrib/glPopAttrib.

That would be nice, except VisKit really doesn't like the idea that OpenGL
state changed outside of VisKit. VisKit doesn't even attempt to provide an
interface to allow an application to do its own rendering outside of
VisKit. As a result, I have no choice but to make OSG play in VisKit's
world.

> Next up would be to use the
> osg::State::haveAppliedMode(),haveAppliedAttribute()
> methansim for telling it that external code has changed the OpenGL
> state.  For instance for the GL_BLEND you'd do:
>
>   state->haveAppliedMode(GL_BLEND);
>
> And then osg::State would know that that state is now dirty and must
> be reapplied.

Unfortunately, this has the same issue as the ::rese() method, as I
described in my previous email: calling haveAppliedMode() potentially sets
last_applied_value to a value that is inconsistent with current OpenGL
state.

It turns out that ::reset() does everything I want it to do with the
exception of how it handles modes.

I've derived my own class "SyncState : public osg::State" and added a
::syncModes() method to it, which simply iterates over the stored modes
and calls either glEnable or glDisable according to last_stored_value. So
now my application simply calls osg::State::reset() followed by a call to
SyncState::syncModes(), then proceeds with OSG rendering. This works for
our special case rendering and doesn't invade OSG.

Thanks,
   -Paul

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to