 |
Unfortunately this was design decision for shadow maps. There were some issues when front faces did not cast shadows, I don't even remember what exactly. For closed solids, there is conceptually no difference. |
 |
But for modular walls and other models using one-sided planes this is huge change. It means they all need back faces that won't ever be seen by players, as they're needed for proper shadow casting. It fundamentally changes how you plan models and optimize faces, from the idtech4 way (Carmack's reverse) to what you have in Unreal and the like. This way you might render (!) the whole array of both stock and custom models incompatible with proper shadow casting. |
 |
"For closed solids, there is conceptually no difference." That's not true, actually. It could impact any shadow solid that is embedded into a visual model, like Spook's screenshot above. Any model using a shadowmesh could have a surface that sticks out a little from the visual model. Under the regular shadowcasting system this would not cause problems, but now a shadow could be cast directly on the object itself. |
 |
> It means they all need back faces that won't ever be seen by players, as they're needed for proper shadow casting. Quite the opposite AFAIK The D3 uses back faces only for stencil shadows. I tried it with shadow maps and it almost worked with the notable exception of peter-panning. The workaround (bigger depth compare margin) caused shadow noise on thin objects like dining plates. Polygon offset didn't help much. I proposed to exclude thin objects from shadowing but the mod went the other way. The grim reality is that 2.07 shadow maps are generated for all faces, back and front. Yeah, the shadow mesh can't stick out for sure with front face shadows, but what do you suggest? Switch to back faces? I recall another bug with back faces - some back faces were getting shadow noise due to normal map / triangle normal mismatch. (Think balcony columns in Lockdown) |
|
|
"Any model using a shadowmesh could have a surface that sticks out a little from the visual model" --- for what purpose are shadowmeshes used? Doing so for performance might be obsolete: shadow maps don't suffer much from geometric complexity, and even stencil shadows after 10 years should cope well with our low-poly meshes. |
|
|
What if we disable front-face rendering only for shadow meshes? I mean: normal solid objects are rendered as usual, but various shadow helpers have only backfaces enabled when creating shadow maps. |
|
|
All our complex models include shadow meshes. I've seen no evidence that they're obsolete--in most scenes it is the shadow tris that drives down FPS. Even if they were obsolete, removing them is a non-trivial task, because it would require changing the current textures of hundreds of models to shadow-casting ones, breaking all custom skins created for those models. "What if we disable front-face rendering only for shadow meshes?" All shadowmeshes use texture/common/shadow or texture/common/shadow2, so they would be easy to isolate. |
|
|
I guess shadowmaps are heavy in triangles. Having the six cube faces and no face culling it's reasonable to expect 12x triangle count on the shadow pass comparing to interaction itself. Making the shadow materials back-only might be actually least painful. It does add some more complexity to the front end code though. On the other hand it could be the other way around - make all materials back only except the few select that actually need front faces. |
|
|
You cannot distinguish materials which need it from material which don't, because it does not depend on material at all. It depends on geometry of the object and surrounding objects. |
|
|
Umm We do have material modifiers like "twosided" If that depends on material then I'd say shadow sidedness can apply as well even if by precedent |
|
|
Added r_shadowMapCullFront cvar Needs testing |
 |
99% working! A few edge cases with severe shadow acne: https://forums.thedarkmod.com/index.php?/topic/18818-soft-shadow-progress/&do=findComment&comment=446906 and some light leaks. |
|
|
"Quite the opposite AFAIK" I didn't mean back face as invisible other side of a polygon, I meant faces on the back of a model, actual geometry. So with front face shadow casting, a wall module will have to have a thickness, as it can't be a plane with some geometry just on one side. |
|
|
"I didn't mean back face as invisible other side of a polygon, I meant faces on the back of a model, actual geometry. So with front face shadow casting, a wall module will have to have a thickness, as it can't be a plane with some geometry just on one side. " I can't see know where that comes from No, you don't need back faces for walls, in any case With front face shadowing, walls always cast shadows With back face shadowing, walls only cast shadows for lights "behind the corner". This is obviously a faster path. The peter-panning effect is always there for walls but usually you can't see it because they have no back faces. With models like bottles for example, back face shadowing causes peter-panning because it's easy to look at the bottle 'against' the light. |
|
|
https://i.postimg.cc/hPcXgfzX/obraz.png With front face shadowing, this wall will not cast shadows when the light is on the back side. If this was an outer wall module with window, and I'd want to have a light source outside the building (sun, moon, lantern, etc.), then I'd have to either make it a thick wall or clone it and turn 180° (or flip polygons, basically). I have to do that in my Unity project with sunlight coming through the windows. With original idtech4 shadow-casting, this is not a problem. |
|
|
Maybe I do not know the right terms which leads to misunderstanding What I call "front face shadowing" in TDM is shadowing all faces. I call it 'front' as opposite to 'back face shadow' which only uses the back faces. Stencil shadows AFAIR uses back faces only for shadowing. So you'll get your sunlight shadows. With shadowmaps the default setting is all faces. You'll get the shadows again, with no additional effort. Even with shadow face culling, using the back faces only again, will, again, give you the shadows. I can't say for Unity, but in TDM shadows are always there, as long as geometry seals and you're not in the void. |
|
|
Alright, so there are possibilities, that's good to hear. Both Unreal Engine and Unity require solid walls in this case, as only the polygons facing the light source cast shadows (unless double-sided option is checked). |
|
|
Physically, it makes perfect sense, as the front, lit triangles are the ones casting shadows But I suspect with shadow volumes it caused some light leaking/shadow noise (and it does happen with back face stencil shadowing too, just extremely rare) And, back face shadowing saves LOTS of fillrate on wall shadows, at least in the case of shadow maps |
|
|
Most fixes are in 2.08 Further work exists in SVN but appears to be deemed to risky for inclusion the late in 2.08 beta. Moving to 2.09 |
- Anonymous
