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
