Hello J-S,
> * Vec3dArray did not exist in 2.2, so I replaced it with Vec3Array (in
> ConvexHull.cpp), which shouldn't be a problem for small scenes I guess.
This should not be an issue, because its used only for Debuging code.
> * The compiler didn't like the const qualifier on
> MinimalDrawBoundsShadowMap::CameraPostDrawCallback::operator() because
> ViewData::performBoundsAnalysis is not declared const. I don't know why
> this was not a problem when compiling your original project (with the
> same compiler)...
I belive there were few changes in Camera Draw callbacks since 2.2. Maybe
they were related. Making the code const friendly is something I neglected
but these issues should be easy to fix when people report them. You can fix
it in your version and send me for inclusion.
> * osgShadow::ShadowMap has a setLight(osg::LightSource) - not that
> important because I can just setLight(lightSource->getLight()) but might
> be nice to include anyways.
Frankly, this was a deliberate choice. Light casting shadows is selected by
osg::Light ptr during cull phase. I wanted to make it clear for users. I
know that osgShadow::ShadowMap has setLightSource method but I believe that
its not safe. If users call ShadowMap::setLightSource then change Light for
this lightSource ShadowMap may start to find other lights in cull phase and
cast wrong shadows.
> * There's a setTextureUnit() method, with an associated uniform that was
> then used in the shaders. That's useful if people want to use your
> shaders but want to do multitexturing - they might want to move the
> shadow texture unit down to another texture unit. And it's also useful
> if people want to replace your shadow shaders - they don't need to
> hard-code the unit number, just use the uniform.
Sampler uniforms are there. I thought have added these get/set methods ;-) I
will do it.
> * There was a setAmbientBias() method. Not sure if that's relevant in
> your implementation (I remember you talking about this, but don't
> remember the specifics).
For AmbientBias to work properly Ambient lighting had to be zeroed. Thats
why I have added main Vertex shader to avoid using AmbientBias completely.
> * The old interface for shaders in ShadowMap was clearShaderList(), then
> addShader() n times. I like your interface better actually, since it
> allows changing just the main shader and using the shadow
> technique-specific shader fragment for shadow calculations. But I wonder
> what would happen if I set the main shaders to be complete shaders, and
> set the shadow shaders to 0. Would that work? If so, then you could
> emulate the old API that way to provide backwards compatibility.
It should work. If it does not, not much should be fixed to get it work. But
for other changes in shaders and uniforms I would prefer if user derive its
class from certain technique and override shaders, add uniforms and maybe
other variables in virtual ViewData::init. I think that clearShaderList was
bit bit incomplete solution. At least without accompanying clearUniformList
method. One has to override osgShadow::ShadowMap anyway to get it done
right.
> Just FYI, when I ran one of our samples (small scene, about 200 units
> square, and one directional light source) with your shadow code using
> StandardShadowMap, it worked well. Using any other shadow technique,
> though, I had no shadows. The symptom I saw was that the bounding volume
> calculation seemed to be completely off, and didn't include any objects,
> so the shadow map was empty. Displaying the debug HUD confirmed that
> this seems to be what's happening.
If its not secret goverment project ;-) you may send it to me and I may try
to fix it. There is a chance that this is the issue I observed and fixed
recently.
> Just to test it out, I tried to replace Vec3dArray by Vec3Array in your
> original project, and compiled it, and it didn't exhibit this problem,
> so I don't think it's directly related to that. It may be some other bug
> that was fixed between OSG 2.2 and current SVN. Any idea?
Nope, no idea. Its interesting because this array is only used when
Debug HUD is active. Maybe I have ovelooked something important.
> I probably won't be able to follow this up until early September,
> because I won't be in the office until then (Siggraph, then vacations).
> And then I might even be moving our whole framework to OSG 2.6, and then
> it should work, so it may be moot anyways. I just wanted to let you know
> what I had tried and give you some feedback.
Thanks for support, I have refactored LispSM to use templates and fixed the
issue I mentioned last time. I have made this template approach bit more
open to make adding other techniques easier. It should be now relatively
simple to mix other projections like Trapezoidal with all three
MinimalXXXShadowmMaps bases. I have also modified test exmple a bit. But I
had no time to complete osgShadow example changes and test it further. I
hope to post this new version in this weekend. September sounds good ;- ) I
am also planning some vacations this month.
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.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
