View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004980||The Dark Mod||Graphics||public||25.01.2019 23:57||13.04.2019 17:26|
|Product Version||TDM 2.07|
|Target Version||TDM 2.08||Fixed in Version|
|Summary||0004980: Front-facing shadow face casts back-shadow when it should not|
|Description||Disparity exists between r_shadows 1 and r_shadows 2 on how shadow faces cast shadows vis a vis self-occlusion. Screenshots down below illustrate the disparity. To see it in action,|
|Steps To Reproduce||Create a room in DR, place a bright light.|
Create a tall brush to the side of the light and texture it with common/shadow.
In-game, observe the difference between r_shadow 1 and 2.
|Additional Information||Screenshots in this post: http://forums.thedarkmod.com/topic/19774-beta-testing-207/?p=433236|
Where in the post I state that singlepass seems to affect this, on beta 7 it no longer seems to do so.
|Tags||No tags attached.|
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.|
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
|25.01.2019 23:57||Spooks||New Issue|
|31.01.2019 17:26||stgatilov||Note Added: 0011527|
|31.01.2019 20:02||Judith||Note Added: 0011529|
|09.02.2019 16:50||Springheel||Note Added: 0011559|
|09.02.2019 16:51||Springheel||Note Edited: 0011559||View Revisions|
|10.02.2019 09:00||duzenko||Note Added: 0011563|
|10.02.2019 09:01||duzenko||Note Edited: 0011563||View Revisions|
|10.02.2019 09:04||duzenko||Note Edited: 0011563||View Revisions|
|10.02.2019 10:52||stgatilov||Note Added: 0011564|
|10.02.2019 11:06||stgatilov||Note Added: 0011565|
|10.02.2019 14:26||Springheel||Note Added: 0011566|
|10.02.2019 14:53||duzenko||Note Added: 0011567|
|10.02.2019 14:54||duzenko||Note Edited: 0011567||View Revisions|
|10.02.2019 15:00||duzenko||Product Version||SVN => TDM 2.07|
|10.02.2019 15:00||duzenko||Target Version||=> TDM 2.08|
|10.02.2019 15:03||stgatilov||Note Added: 0011568|
|10.02.2019 16:08||duzenko||Note Added: 0011569|
|10.02.2019 16:08||duzenko||Note Edited: 0011569||View Revisions|
|13.04.2019 17:26||duzenko||Note Added: 0011733|