Hi Wojtek,
Nope, receivesShadowMask is generally ignored in ViewDependentShadows.
Exception in MinimaDrawBoundsShadowMap but there it is used only to
approximate shadow volume which is later additionaly refined.
OK, thanks for the clarification.
Problem is that implementing receiveShadowMask without messing with
shaders/and uniforms during render traversals would probably require
splitting cull traversal into two traversals one for receiveShadowMask
nodes and one for those without it. Two cull traversals probably mean
two sets of render stages and possible issues with bin sorting.
That's what Cedric did, and I agree that it might introduce issues.
I guess that alternatively one may use shadow shader and special uniform
which would activate shadow map for nodes with receiveShadowMask I
suspose thats what J-S did.
Not exactly, in my application there is no relation between
receivesShadowMask and the uniform variable. I simply don't use the
receivesShadowMask. When I want a node to not receive shadows I simply
set the uniform to false.
So in my architecture, the castsShadowMask is used to remove nodes from
the shadowMap traversal, but then when rendering the uniform is checked.
I have contemplated ways of syncing the uniform to the nodemasks, but in
the end it's not that useful and would introduce a traversal per frame
to make sure the values stay in sync.
And I think its ok when done explicitly by
end user programmer. But such approach on middleware/library level would
probably mean adding aditional uniforms and/or shaders into stategraph
according to node maks found while culling. I am not sure if this is
fully acceptable and risk free. This also means that shadow shader would
be used for all nodes even for those without receiveShadowMask. If one
would expect that shadowing would not touch any aspect of
receiveShadowMask free nodes he could be unpleseantly surprised as
shaders usually make some shortcuts and sacrifice some of fixed pipeline
functionality.
I totally agree, it's not for the library to make these decisions but
for the application programmer.
In my opinion generic shadow algorthm which could be used without
modification with all types of database and types of aplication was not
yet found. And I would not try to make such algorithm. Anyone should
expect that if certain approach does not work for their case they need
to either derive their own shadow from exisiting classes or create their
own solutions.
Again I agree, the library can provide some tools but a totally
plug-and-play shadow algorithm is (in my opinion) not possible since it
depends on too many factors which only the application programmer can
know about.
Just to be clear: when I was suggesting to use uniforms or to place
non-shadow-receiving nodes in a different subgraph not under the
ShadowedScene, I was not suggesting that osgShadow should do that. I was
saying that it was the user's responsibility. It's not too hard to do
but if you need that functionality you need to do it yourself.
Thanks for your clarifications Wojtek.
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
