Hi JS, Cedric, Wojtek
Jean-Sébastien Guay wrote:
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
I guess my last post is way out of sequence now. Serves me right for
walking away from half composed message for a few hours and then
pressing send when I got back before I checked new mail. At least my
original message provoked some debate, which was what I wanted. Sorry
Cedric, I had done a scan back through the list but I only noticed JS's
posts.
It would be nice to have a non fragment shader/uniform approach. I
think my cull callback approach is doable but messy. But a least most
of the mess is at graph construction/teardown time. It might be better
to add a callback facility into osgUtil::cullVisitor that gets called
before each node is processed and can push back some extra state. But
it all eats cycles.
Retaining the ReceivesShadow bit/bits is good for non rendering
traversals such as the one Wojtek mentioned and at least they are there
for use as state by cull callbacks.
Roger
|
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
