View Issue Details

IDProjectCategoryView StatusLast Update
0004980The Dark ModGraphicspublic20.05.2020 15:02
ReporterSpooks Assigned Toduzenko  
PrioritynormalSeveritynormalReproducibilityalways
Status assignedResolutionopen 
OSWindowsOS Version7 
Product VersionTDM 2.07 
Target VersionTDM 2.09 
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: 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.
TagsNo tags attached.

Activities

stgatilov

stgatilov

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

Judith

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

Springheel

09.02.2019 16:50

administrator   ~0011559

Last edited: 09.02.2019 16:51

View 2 revisions

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

duzenko

duzenko

10.02.2019 09:00

developer   ~0011563

Last edited: 10.02.2019 09:04

View 3 revisions

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

stgatilov

stgatilov

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

stgatilov

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

Springheel

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

duzenko

10.02.2019 14:53

developer   ~0011567

Last edited: 10.02.2019 14:54

View 2 revisions

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.

stgatilov

stgatilov

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

duzenko

10.02.2019 16:08

developer   ~0011569

Last edited: 10.02.2019 16:08

View 2 revisions

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

duzenko

duzenko

13.04.2019 17:26

developer   ~0011733

Added r_shadowMapCullFront cvar
Needs testing
nbohr1more

nbohr1more

13.05.2020 04:35

developer   ~0012498

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

Judith

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

duzenko

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

Judith

13.05.2020 14:34

reporter   ~0012504

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

duzenko

13.05.2020 18:22

developer   ~0012505

Last edited: 13.05.2020 18:23

View 4 revisions

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

Judith

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

duzenko

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
nbohr1more

nbohr1more

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 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
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 View Revisions
13.05.2020 18:22 duzenko Note Edited: 0012505 View Revisions
13.05.2020 18:23 duzenko Note Edited: 0012505 View Revisions
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