HI Alexandre, It's a while since I touched the code, but I think with the ViewDependentShadowMap the casters also normally need to be a receiver as it'll self shadow, but there may also be the constraint that the actual rendering of objects is done via the shadow receivers pass. I vagually recall that there might have to been a lot of code and CPU cost associated with binning casters but not receivers.
The bit you'd normally want to toggle off is the terrain being a shadow caster. Robert. On 4 February 2015 at 23:34, Alexandre Vaillancourt < [email protected]> wrote: > Thanks Robert, > > The shadow technique being used is ViewDependentShadowMap. > > I understand that trying to find where the issue comes from is like > searching for a needle in a stack of hay. I'm trying to figure out myself > how the system is being programmed as I'm not at all familiar with that > aspect of OSG and the way we're using it regarding shaders/shadow, as I'm > not the one who programmed it, so, don't worry, I'm not expecting exact > reasons why stuff don't work. > > Checking the diff between 3.1.1 and 3.2.0 regarding shadows does not > reveal anything that I would think of being a game changer, so this is why > I'm confused. > > > I'm under windows 8.1, visual studio 2013, GeForce GTX 780 Ti, driver > version 347.09. > > In the mean time, I've been able to find a way to have the objects visible > again by changing the node mask of the main node shadowed and the node mask > of the nodes that were hidden. > > > > If anyone cares (that's not much of importance :P), here are the rough > changes I did : > with: > unsigned int CAST_SHADOW_TRAVERSAL_MASK = 0x00000002; > unsigned int RECEIVE_SHADOW_TRAVERSAL_MASK = 0x00000001; > shadowSetting->setCastsShadowTraversalMask( CAST_SHADOW_TRAVERSAL_MASK ); > shadowSetting->setReceivesShadowTraversalMask( > RECEIVE_SHADOW_TRAVERSAL_MASK ); > > the ShadowedNode was set like this > mEnvShadowedNode->setNodeMask( mEnvShadowedNode->getNodeMask() & > CAST_SHADOW_TRAVERSAL_MASK ); // Now set to 2... maybe nodes below were > culled because of that, I could not figure it out. > > and the nodes in the ShadowedNode > mobileObject->setNodeMask( CAST_SHADOW_TRAVERSAL_MASK ); // assume cast > AND receive > staticObject->setNodeMask( RECEIVE_SHADOW_TRAVERSAL_MASK ); // assume > receive only > > So assuming that the CAST mask is no longer sufficient to have it receive > as well, I removed the nodemask setting from the mEnvShadowedNode and the > mobileObject (now using the default values of all 1) and I set the nodemask > to the static object to something like: > staticObject->setShadowMask( staticObject->getShadowMask() & ! > CAST_SHADOW_TRAVERSAL_MASK ); // This way we disable the shadow casting, > while keeping the receiving and keeping the other parts of the mask. > > Now it displays as expected, but I'm not sure yet if there are other parts > of the code that no longer behave appropriately. > > > > > -- > Alexandre Vaillancourt > > 2015-02-04 9:31 GMT-05:00 Robert Osfield <[email protected]>: > >> HI Alexandre, >> >> On 4 February 2015 at 13:23, Alexandre Vaillancourt < >> [email protected]> wrote: >> >>> I've been told that objects that were casting shadow were automatically >>> set to receive shadows as well, and that it was an implementation >>> constraint that was not avoidable. >>> >>> Has this constraint been resolved, making it so that if we want an >>> object to cast and receive shadows we have to set both mask explicitly (not >>> only "cast")? >>> >> >> This will depend upon the ShadowTechnique being used. I don't recall the >> which ones have what constraints though, been a couple of years since I've >> worked on osgShadow. >> >> I'm trying to figure out issues that seemed to have appeared after from >>> upgrading from 3.1.1 to 3.2.0 but I can't figure out what went wrong. (Some >>> objects went missing from sight.) >>> >> >> There are too few details for us to be able to guess what might be >> wrong. We don't know what shadow technique you are using, the data you are >> working with, what types of objects are going missing, what >> platform/hardware you are working on. >> >> Robert. >> >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
