The fix was to check whether glGetString( GL_VERSION ) returned a null pointer (Ref. svn diff below). The altered src/osg/GLExtensions.cpp is zipped and attached to this email."
"Soft shadow mapping is basically the same as hard shadow mapping beside that
it uses a different fragment shader.
So for me it makes sense that osgShadow::SoftShadowMap is derived from
osgShadow::ShadowMap, this makes it easier to maintain the two classes.
Additional SoftShadowMap also provides the same Debug methods as ShadowMap."
I think I may have discovered a bug in osgShadow/ShadowMap.cpp that results in incomplete shadows being generated.
The problem seems to caused by an incorrect interpretation of the spot light cutoff angle. The valid ranges for spot cutoff are 0-90 and 180, i.e half the 'field of view' for the spotlight. Whereas the shadow map code seems to assume the the spot cutoff is equal to the field of view. This results in the shadows generated by the spotlight getting clipped at half the spot cutoff angle.
I have fixed this in my copy of ShadowMap.cpp:
===============================
//Original code from OSG 2.6:
if(selectLight->getSpotCutoff() < 180.0f) // spotlight, then we don't need the bounding box
{
osg::Vec3 position(lightpos.x(), lightpos.y(), lightpos.z());
float spotAngle = selectLight->getSpotCutoff();
_camera->setProjectionMatrixAsPerspective(spotAngle, 1.0, 0.1, 1000.0);
_camera->setViewMatrixAsLookAt(position,position+lightDir,osg::Vec3(0.0f,1.0f,0.0f));
}
===============================
// My modifications:
float fov = selectLight->getSpotCutoff() * 2;
if(fov < 180.0f) // spotlight, then we don't need the bounding box
{
osg::Vec3 position(lightpos.x(), lightpos.y(), lightpos.z());
_camera->setProjectionMatrixAsPerspective(fov, 1.0, 0.1, 1000.0);
_camera->setViewMatrixAsLookAt(position,position+lightDir,osg::Vec3(0.0f,1.0f,0.0f));
}
This change seems correct for spot cutoff in the range 0, 90, but since OpenGL doesn't claim to support cutoffs >90 && <180, I'm not sure how shadow map should deal with those cases, but ignoring spot cut off greater than 90 here seems reasonable to me.
"
> Using QOSGWidget - QWidget + osgViewer creating the graphics context.
>
> Windows Error #2000: [Screen #0] GraphicsWindowWin32::setWindow() - Unable
> to create OpenGL rendering context. Reason: The pixel format is invalid.
>
>
>
> And then the following fate error pops up:
>
>
>
> The instruction at "0x014c7ef1" referenced memory at "0x000000a4", The
> memory could not be "read".
>
> Click on Ok to terminate the program
>
> Click on CANCEL to debug the program
>
>
- adds display of options when using osgconv --formats.
- adds useGroupPerFeature option to have each feature in a separate group. Usage: OSG_OPTIMIZER=OFF osgconv -e ogr -O addGroupPerFeature <infile> <outfile>
"
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."
mode. Nevertheless, the code doesn't acknowledge that, so I had problems with
debug versions of the library not being able to open their plugins whereas
the release versions worked fine.
I have made the same changes in Registry.cpp that are available for the rest
of platforms appending that "d" to their plugins. I have also updated the
CMakeLists.txt file to get "_DEBUG" defined at compilation time. I have
copied the already existent conditional block because of cmake's bizarre
operator precedence. Since Cygwin defines both CYGWIN and WIN32, the
following would suffice:
IF(CYGWIN OR UNIX AND NOT WIN32 AND NOT APPLE)
Sadly, it actually doesn't work, so I wrote a new conditional block just for
Cygwin. I could join the two blocks when the parentheses support is added in
newer versions of cmake."
polygon offset complicate. so i looked for a solution to remove this offset.
i changed the shader, also the filtering (default: on) use now a correct 3x3 filter:
1 0 1
0 2 0
1 0 1
div: 6
of course a better one would be
1 2 1
2 4 2
1 2 1
div: 16
but this isn't as performant as the simple filter above is. because we need only 5 texture lookups instead of 9, and the result is still good, if you wish we can add a enum to change the pcf filter type once, if there is a need.
testet on NVidia Quatro 570M and on ATI Radeon X1600
"
unfort. i couldn't test it on any ATI system. may there will be still another problem there. if there are still some artefacts. we should try out better fZOffSet value
"
if(
(!win || win->getVisibilityMode() == Window::VM_PARTIAL) &&
!win->isPointerXYWithinVisible(x, y)
) continue;
But it probably should be
if (!win || (win->getVisibilityMode() == Window::VM_PARTIAL) && !win->isPointerXYWithinVisible(x, y)))
continue;
The effect of the bug is to segfault if a non-osgWidgets::Window node hasn't been excluded from picking via NodeMask."
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 ...
"
