Hi Kristopher, I've reviewed you changes and have taken the solution one step further by introducing a new convinience method ShadowTechnique::computeOrthogonalVector(const osg::Vec3& direction) const that computes the optimum vector that is orthogonal to the look vector. This approach should be more robust that just having two hardwired vectors. I've also added use of the new method into both ShadowMap.cpp and ShadowTexture.cpp, the two places in osgShadow with used setViewMatrixAsLook().
Could you updated to the latest in svn/trunk and test to make sure the issues you were seeing are now addressed. Thanks, Robert. On Wed, Feb 3, 2010 at 4:20 PM, Kristopher J. Blom < [email protected]> wrote: > > Hallo Robert and all, > > Attached is a patch for an issue with ShadowMaps (and, therefore, also > effects SoftShadows). Because the upVector for the camera frustum was > hardcoded to be +Y, positional lights can cause an invalid matrix > resulting in no shadows. Defining a spotLight going directly down shows > this effect well (positional lights are dependent on the center of the > bounding box and, therefore, this issue is more difficult to reproduce > and to understand what is happening when it does). > > The patched version (against today's repository) simply parameterizes the > upVector and checks for it being the same as the view direction. If it > is, it sets it to +Z (arbitrary, but then so is +Y). > > cheers > -Kris > > p.s. I haven't checked if this issue effects any other Shadow > implementations. > > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
