"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."
CMakeLists.txt changes: "I installed latest Cmake(2.6.1) on a new machine and got a CMP008
warning from cmake. This fix set up osg to use the old behaviour which
have worked before. We might set this to NEW but I need to do more
testing first. I'l be able to test this on winxp with msvc80/90 and
ubuntu hardy with gcc-4.2.
quote from cmake cvs log
policy CMP0008 to decides how to treat full path libraries that do not
appear to be valid library file names. Such libraries worked by
accident in the VS IDE and Xcode generators with CMake 2.4 and below."
OsgMarcroUtils.cmake changes: "On Philips suggestion truncated a redundant if/else construction in
OsgMacroUtils to avoid developer warnings in cmake-2.6.1 concerning
cmake policy CMP0008 which allows full paths to libraries only with
valid library names
"
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
"
I have found some errors on the example osgGeometryShaders. It's about the varying in the geometry shader.
take a look at the varying vec4 v_color.
In the vertex shader, v_color is initialized to gl_vertex
then in the geometry shader v_color is initialized to gl_PositionIn[0]
and in the fragment shader v_color is used as the fragment color.
Try to initialized v_color to vec4(1.0, 0.0, 0.0, 1.0) in the vertex shader and comment the line :
" v_color = v;\n" in the geometry shader, and you will see the lines as black !
It's because you have to use keywords in and out.
extract from : http://www.opengl.org/registry/specs/EXT/geometry_shader4.txt :
in - for function parameters passed into a function or for input varying
variables (geometry only)
out - for function parameters passed back out of a function, but not
initialized for use when passed in. Also for output varying variables
(geometry only).
Then for a geometry shader, a varying must be an array :
extract from : http://www.opengl.org/registry/specs/EXT/geometry_shader4.txt :
Since a geometry shader operates on primitives, each input varying variable needs to be
declared as an array. Each element of such an array corresponds to a
vertex of the primitive being processed. If the varying variable is
declared as a scalar or matrix in the vertex shader, it will be a
one-dimensional array in the geometry shader. Each array can optionally
have a size declared. If a size is not specified, it inferred by the
linker and depends on the value of the input primitive type.
Here is a patch based on the svn version of osg that correct that.
"
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 ...
"
