osg::ColorMask* leftColorMask = _renderStageLeft->getColorMask();
if (!leftColorMask)
{
leftColorMask = new osg::ColorMask();
_renderStageLeft->setColorMask(leftColorMask);
^^^^ here it said right, I think this should be Left.
}
// ensure that right eye color planes are active.
osg::ColorMask* rightColorMask = _renderStageRight->getColorMask();
^^^^ similar here, I think this should be right
if (!rightColorMask)
{
rightColorMask = new osg::ColorMask();
_renderStageRight->setColorMask(rightColorMask);
}
and i further removed an unnecessary setColorMask."
set.
The optimization is based on the observation that matrix matrix multiplication
with a dense matrix 4x4 is 4^3 Operations whereas multiplication with a
transform, or scale matrix is only 4^2 operations. Which is a gain of a
*FACTOR*4* for these special cases.
The change implements these special cases, provides a unit test for these
implementation and converts uses of the expensiver dense matrix matrix
routine with the specialized versions.
Depending on the transform nodes in the scenegraph this change gives a
noticable improovement.
For example the osgforest code using the MatrixTransform is about 20% slower
than the same codepath using the PositionAttitudeTransform instead of the
MatrixTransform with this patch applied.
If I remember right, the sse type optimizations did *not* provide a factor 4
improovement. Also these changes are totally independent of any cpu or
instruction set architecture. So I would prefer to have this current kind of
change instead of some hand coded and cpu dependent assembly stuff. If we
need that hand tuned stuff, these can go on top of this changes which must
provide than hand optimized additional variants for the specialized versions
to give a even better result in the end.
An other change included here is a change to rotation matrix from quaterion
code. There is a sqrt call which couold be optimized away. Since we divide in
effect by sqrt(length)*sqrt(length) which is just length ...
"
The vertical separation not actually displayed as it is set. So some
display the up and down stereo images style will not be correct.
Someone may forget to change the "Horizontal" to "Vertical" after
copying and pasting the code from above HORIZONTAL_SPLIT code segment.
I've attached the file. By replacing the incorrect "Horizontal" to
"Vertical", the bug is gone.
"
use the osg::State::applyMode for enabling/disabling certain while
rendering the stencil mask. Previously some of these calls were
overriding the scene graph states because the global state was not
aware of this change.
"
to optimize away duplicate state with dynamic, static and unspecified DataVarience. By default
the code now optimizes away duplicate state with either static and unspecied state, previously
it was just handling static state.
1) The "highest res" child is assumed to be the child with index "getNumFileNames()-1" or "getNumChildren()-1". As a result, PagedLODs that do not sort children from furthest to nearest will intersect with the wrong child. (see attached "case1.osg" to reproduce this problem.)
2) The code assumes there is only one highest res child. As a result. PagedLODs with multiple children at the same highest res range can only intersect one of those children. ("case2.osg" demonstrates this issue; you can only pick the quad on the right.)
I've attached a modified IntersectionVisitor.cpp that attempts to resolve these issues. It identifies a highest res range based on the range mode, then continues traversal on all valid children corresponding to that range description. Only in the case of a malformed PagedLOD does the code fall back to getting the last child in the list.
"
From Robert Osfield, made a range of changes to Terry's visitor integrating it into osgUtil::Optimizer and
changing the code to use a style more like the rest of the OSG.
viewport settings in stereo mode. It seems that the SceneView::cull()
method will pass the full size viewport to the left/right
cullvisitors, instead of the modified stereo viewport. I made quite a
few changes to SceneView to fix the issue. The SceneView::cullStage()
method will now receive the viewport as an argument, instead of using
the global viewport. The SceneView::cull() method will pass the
modifed viewport to cullStage when rendering in stereo.
There are 2 new private methods computeLeftEyeViewport() and
computeRightEyeViewport() that will compute the stereo viewports. I
also modified the draw() function so it applies the correct viewport
to the prerender stages. These changes are only necessary for
horizontal/vertical split stereo."
via StateSet::setNestedRenderBin(bool) whether the new RenderBin should be nested
with the existing RenderBin, or be nested with the enclosing RenderStage.
This was easy to implement simply by overriding IntersectionVisitor::apply(PagedLOD). My question is: Are there any opinions on whether this should be the default behavior? If it makes sense, I will submit the change; if not, no worries."
Finally it seems to not come from the empty geode. The origin of the problem seems to be the uniform initialization during the building of the program which call a glUseProgram.
If your scene never display the node that contains the shader and if there is no other shader on the scene, this "glUseProgram" is the only one that is called during your simulation. So, this shader is applied on all the scene.
I fix this bug by switching off the shader (by calling glUseProgram(0) ) during the compilation of a state which does not contain the shader.
"
From Robert Osfield, refactored the FrameBufferObejcts::_drawBuffers set up so that its done
within the setAttachment method to avoid potential threading/execution order issues.
