Overriding noselfshadows

[Springheel]

I've got a situation in a map where there are papers scattered on the floor. These paper models use default paper textures that have "noselfshadow" in the material stage. When an AI that also has "noselfshadow" set walks over the papers, the floor gets a cast shadow from the AI, but the paper doesn't.

 

I realize I could make a custom material that removes the "noselfshadow" for the paper textures, but is there any spawnarg that can force an entity to cast (and more importantly receive) shadows?

[nbohr1more]

I don't think so.

 

I recall seeing something about forceShadows as a keyword for lights but I don't think

the code was complete.

[duzenko]

That would also mean that multiple AI won't get shadows from each other

[stgatilov]

From iddevnet:

noShadows         Don't cast shadows

noSelfShadow      This material doesn't cast shadows on the model it's on (but it does on other models)

forceShadows          Allows nodraw surfaces to cast shadows

Could someone explain me why "noselfshadow" objects don't receive shadows from other entities?

It does not follow from the name, and does not follow from description.

[Snehk]

Check this wiki article, it might explain it.

 

http://wiki.thedarkmod.com/index.php?title=Noselfshadows

[Obsttorte]

Some of the shadowmesh materials used on ai (for example the forger or the priest) have noselfshadows set in their material defs. Hence, from the description linked by Snehk, they won't cast shadows on surfaces using noselfshadow materials, too. It appears that this effect is not caused via some condition in the code, but is a direct effect of the way how the renderer operates, so it is unlikely that this will be changeable that easely.

 

I agree with stgatilov that the naming isn't very intuitive here, as it implies that an object does not cast shadows on itself, but doesn't imply that it also affects how it will relate to shadows cast on other entities or the shadows it receives from them.

[Springheel]

It's a strange way for it to work, agreed.

[stgatilov]

In the current implementation noselfshadows is a hack, meaning that bad consequences happen at some moment.

 

In order to implement a 'correct" noselfshadow rendering, it is necessary (while rendering every such object) to have all shadow volumes in stencil buffer except the volumes cast by the object itself.

For an efficient implementation of such feature, it is necessary to not only add shadow volumes into stencil buffer, but also subtract them.

 

On the other hand, isn't it possible?

Render all shadows into stencil buffer first, then render all normal objects, then for each noselfshadows object: render its shadow volume in "subtract" mode, then render the object to frame, then render same shadow volume in "add" mode.

This is not very efficient of course

 

Anyway, I guess it is possible to add something like forceSelfShadows, but it will probably make things even more complicated.

[Obsttorte]

In this case the easiest approach is probably to change the material used on the paper from noselfshadows to noshadows. This way it doesn't cast shadows on its own (and therefore not on itself), but will receive shadows.

 

I would assume that noSelfShadows is mainly intented for models with rather complex shadowmeshes or for those who are moving all the time, like on ai. This isn't really the case for such a small object like a paper.

[Springheel]

In this case the easiest approach is probably to change the material used on the paper from noselfshadows to noshadows. This way it doesn't cast shadows on its own (and therefore not on itself), but will receive shadows.

 

I would assume that noSelfShadows is mainly intented for models with rather complex shadowmeshes or for those who are moving all the time, like on ai. This isn't really the case for such a small object like a paper.

 

The only cases noselfshadow is (or at least should be) used is on rounded objects with no shadowmesh, where normalmaps make the appearance of a smooth curve but triangles of shadow can be cast by the corners of polys. Kind of an oversimplified image below, but even though the blue polys that stick up are smoothed to look like a curve (red), the shadows they cast are still sharp triangles, which ruins the illusion especially when they fall on the object itself.

 

In this case, I assume the keyword was originally added for rounded scrolls.

[Obsttorte]

That's another possibility I haven't thought of. Good catch.