Hi Robert, the additions sound good to me. I wasn't really happy with the hardwiring, but it required only a single test every frame rather than a calculation so i went with that.
Unfortunately, I haven't been able to the current svn version with my code. Backported to 2.8.2 the new method produce the correct effect. As for the svn: in my VR Juggler based app I cannot load anything using the svn version. I just get black and "Warning: detected OpenGL error 'invalid enumerant' at after RenderBin::draw(..)" as in the thread from gcope: Migrating from 2.8.2 to 2.9.6. However, Garretts fix removes only the warnings and doesn't change that I don't see anything. This effects 2.9.6 and the current svn and occurs both with VR Juggler 2.2.1 and the newest svn versions. All of the osg samples I have tested work just fine, including the osgviewer, so it likely has to do something with how vr juggler calls OSG or using SceneView instead of Viewer. I'll have to look into this, but it'll be a while before I can free up time for this. -Kris On Mon, 2010-03-01 at 12:38 +0000, Robert Osfield wrote: > 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 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
