Hi David,
Thanks for the help.
My pleasure.
While I'm here, is there any reason why the shaded objects shouldn't do
the TexGen in a vertex shader?
They do... :-)
Thinking about it though, I suppose that setting shadowCast to false on
an intermediate node between the mirror and the reflected objects
prevents the cull traverse from ever finding them, so they don't cast
shadows twice. Sounds right? Although I'm still a bit uneasy about what
the mirror might make of the repeated cull traverse attempts... I
suppose I had just better try it out rather than blather on and on.
About your mirror problem, I admit I haven't seen this case. Your
solution (getting the shadow map texture and applying it to nodes not
under the ShadowedScene) might be the best way, I don't know. I have the
opinion that adding too many multiple traversal paths can make things
hard to understand when debugging why something is not rendering
correctly. That's up to you of course.
But thanks for explaining, at least it shows me that I have to keep an
open mind to situations that I haven't seen :-)
I would prefer an OSG wide setting that would be user controlled that
set up some sort of relationship between default texture types and
units(e.g. 0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all
the loaders that cared would be consistent (e.g. 3ds, obj), and that the
shadow map could refer to, and that any shader set could read sampler2D
values from, etc. No idea where this would go, though.
I agree that all this is more complex than it should be. There are a few
things OSG could do to simplify the art pipeline management, but I don't
think it's really under its jurisdiction to do so. Applications will
have different requirements, and even though some can be generalized, in
many cases you want to try out different strategies in order to find the
one that works best given your hardware and application-specific
bottlenecks.
Now, an add-on library could be written that would help unify the art
pipeline. Things like models, textures, mapping of textures to texture
units, shader management, shader generation from chunks of shader code,
effect management, etc. could be made much simpler and more
user-friendly. But as I said, I don't think it's OSG's job to do this.
OSG provides a framework, and this is a bit too domain-specific IMHO.
But it's a pretty large discussion that's bound to have widely different
opinions from different people... I have no authority on OSG (other than
sending submissions to suggest new directions) so I would be interested
in Robert's opinion on the matter.
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
