View Issue Details

IDProjectCategoryView StatusLast Update
0004980The Dark ModGraphicspublic13.04.2019 17:26
ReporterSpooksAssigned To 
PrioritynormalSeveritynormalReproducibilityalways
Status newResolutionopen 
PlatformOSWindowsOS Version7
Product VersionTDM 2.07 
Target VersionTDM 2.08Fixed in Version 
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

developer   ~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

developer   ~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

developer   ~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

developer   ~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

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