Created a new GraphicsThread subclass from OperationThread which allows the
GraphicsContext specific calls to be moved out of the base OperationThread class.
Updated the rest of the OSG to respect these changes.
I added _preDrawCallback member and neccessary access methods plus modified osgUtil RenderStage.cpp to invoke it before all drawInner calls are made. I tried to maintain symmetry with postDrawCallback but you know better where is a proper place for this call ;-)
"
as osg::GraphicsOperation. Unpdated parts of OSG depending upon these.
Added a virtaul bool valid() method to osg::GraphicsContext to allow apps to
test whether a valid graphis context has been created or not.
created local to RenderStage and passed on to rendering code which populated
the RenderInfo UserData, but without the restoring the new UserData to the
main RenderInfo. The local RenderInfo UserData is now passed back to the main
RenderInfo.
handle scenes with multiple views with elements that need coordinating on a per view basis.
Added beginings of new osgText::FadeText class (not functionality yet).
"I've made some changes to osg which I think make it easier to control
the render order of CameraNode's. Instead of using the built-in orders
(PRE_RENDER, POST_RENDER, NESTED_RENDER), you can specify an integer
order. Values less than zero are pre rendered in order. Values greater
than zero are post rendered in order. And a value of 0 is equivalent
to NESTED_RENDER.
The changes should be fully backward compatible. Also, I changed the
RenderStageList type from a vector to a list because I needed to be
able to insert values anywhere in the list.
The reason I made these changes was because I wanted to be able to set
the render order of a CameraNode at runtime without having to reorder
it in the scenegraph."
and later in the final submission message (relating to what has been finally been merged) :
"I've rethought my implementation and came up with something a little
better. The setRenderOrder will continue to take an enum, but will
have an optional orderNum parameter which can be both positive and
negative. I think this method is more intuitive and flexible."
FrameBufferObject.cpp there is also another fix: when initializing a FBO
attachment from a CameraNode attachment, the renderbuffer's format must be
set to the attachment's internal format, not to the image's pixel format.
Another problem is that attaching a renderbuffer to the FBO through
CameraNode is not simple (if not impossible) if you don't intend to specify
an Image object. Probably CameraNode could be enriched with an
"attach(buffer, width, height, format)" method. For example if you attach a
color buffer as a texture whose size is different than that of the
CameraNode's viewport you also need to attach a depth buffer of the same
size, because the depth buffer that is automatically attached by RenderStage
has the viewport's size. FBOs require that all attachment have the same
dimensions, so said setup will fail if you can't specify a custom depth
renderbuffer"
the code path from running a PBuffer as a seperate graphics context (this
was found to be slower than running single threaded so its not worth the
extra complexity).
