View Issue Details

IDProjectCategoryView StatusLast Update
0004980The Dark ModGraphicspublic11.02.2024 21:32
ReporterSpooks Assigned Tocabalistic  
Status acknowledgedResolutionopen 
OSWindowsOS Version7 
Product VersionTDM 2.07 
Target VersionTDM 2.13 
Summary0004980: Front-facing shadow face casts back-shadow when it should not
DescriptionDisparity 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 ReproduceCreate 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 InformationScreenshots in this post:

Where in the post I state that singlepass seems to affect this, on beta 7 it no longer seems to do so.




31.01.2019 17:26

administrator   ~0011527

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.


31.01.2019 20:02

reporter   ~0011529

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.


09.02.2019 16:50

administrator   ~0011559

Last edited: 09.02.2019 16:51

"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.



10.02.2019 09:00

developer   ~0011563

Last edited: 10.02.2019 09:04

> 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)



10.02.2019 10:52

administrator   ~0011564

"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.


10.02.2019 11:06

administrator   ~0011565

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.


10.02.2019 14:26

administrator   ~0011566

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.


10.02.2019 14:53

developer   ~0011567

Last edited: 10.02.2019 14:54

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.



10.02.2019 15:03

administrator   ~0011568

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.


10.02.2019 16:08

developer   ~0011569

Last edited: 10.02.2019 16:08

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



13.04.2019 17:26

developer   ~0011733

Added r_shadowMapCullFront cvar
Needs testing


13.05.2020 04:35

developer   ~0012498

99% working!

A few edge cases with severe shadow acne:

and some light leaks.


13.05.2020 05:16

reporter   ~0012502

"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.


13.05.2020 11:51

developer   ~0012503

"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.


13.05.2020 14:34

reporter   ~0012504

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.


13.05.2020 18:22

developer   ~0012505

Last edited: 13.05.2020 18:23

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.


13.05.2020 18:39

reporter   ~0012506

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).


13.05.2020 18:58

developer   ~0012507

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


20.05.2020 15:02

developer   ~0012525

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

Issue History

Date Modified Username Field Change
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
10.02.2019 09:00 duzenko Note Added: 0011563
10.02.2019 09:01 duzenko Note Edited: 0011563
10.02.2019 09:04 duzenko Note Edited: 0011563
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
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
13.04.2019 17:26 duzenko Note Added: 0011733
13.05.2020 04:35 nbohr1more Note Added: 0012498
13.05.2020 05:16 Judith Note Added: 0012502
13.05.2020 11:51 duzenko Note Added: 0012503
13.05.2020 14:34 Judith Note Added: 0012504
13.05.2020 18:22 duzenko Note Added: 0012505
13.05.2020 18:22 duzenko Note Edited: 0012505
13.05.2020 18:22 duzenko Note Edited: 0012505
13.05.2020 18:23 duzenko Note Edited: 0012505
13.05.2020 18:39 Judith Note Added: 0012506
13.05.2020 18:58 duzenko Note Added: 0012507
20.05.2020 15:02 nbohr1more Note Added: 0012525
20.05.2020 15:02 nbohr1more Assigned To => duzenko
20.05.2020 15:02 nbohr1more Status new => assigned
20.05.2020 15:02 nbohr1more Target Version TDM 2.08 => TDM 2.09
05.12.2020 12:43 stgatilov Status assigned => acknowledged
05.12.2020 12:43 stgatilov Target Version TDM 2.09 => TDM 2.10
15.03.2021 15:44 stgatilov Assigned To duzenko => cabalistic
15.03.2021 15:45 stgatilov Target Version TDM 2.10 => TDM 2.11
04.12.2022 02:59 nbohr1more Target Version TDM 2.11 => TDM 2.12
05.12.2023 01:41 nbohr1more Target Version TDM 2.12 => TDM 2.13
11.02.2024 21:32 Fiver Tag Attached: shadows