View Issue Details

IDProjectCategoryView StatusLast Update
0004079The Dark ModGraphicspublic31.12.2017 07:24
ReporterSteveL Assigned ToSteveL  
PrioritynormalSeveritynormalReproducibilityalways
Status resolvedResolutionfixed 
Product VersionTDM 2.03 
Target VersionTDM 2.04Fixed in VersionTDM 2.04 
Summary0004079: Decals drawing over stuff in front
DescriptionFrom dev forum discussion: http://forums.thedarkmod.com/topic/16914-renderer-roadmap-for-204/#entry364788

//
This may be a minor thing, but I'm hoping it's possible with the new access to depth info to stop decals from being drawn over things that are closer to the player. For example, if I make a door with a decal around the faceplate, that decal will appear over top of the door handle if I back far enough away. I'm noticing this with the exterior building modules. If I attach a window model to a wall that has a built in decal, the decal will draw over top of the window as the player backs away, even though it is actually behind the window.
//
TagsNo tags attached.

Relationships

related to 0004634 assignedstgatilov Inn Business: ambient light on a rug in tavern is not smooth 

Activities

SteveL

SteveL

05.02.2015 12:16

developer   ~0007404

The standard depth tests should be handling this ok without us needing to use a special depth-testing shader program. I guess it must be something to do with how we make sure decals don't z-fight with the surface they are on.. a depth hack of some kind. I failed to spot it in a single step-through of the code last night -- it's not done the same way as it is for particles and player weapons, using explicit depth hack flags -- but I'll try to track it down later.
Springheel

Springheel

05.02.2015 19:39

administrator   ~0007405

It must be something n the material shaders, because it happens with models too, and there's no other difference between a poly with a decal texture and one with another texture.

I can't say I've noticed this effect with anything other than dirt decals, which all use filter blends. Would be interesting to try it with other types of decals.
SteveL

SteveL

07.02.2015 04:37

developer   ~0007406

Ah, that's it. DECAL_MACRO in the dirt decals and some others hacks the depth of the surface.
SteveL

SteveL

07.02.2015 05:11

developer   ~0007409

Posted to forum:
//
This problem looks like a simple incorrect default value for a cvar in the original Doom3 engine. Dirt decals and some others have "DECAL_MACRO" in their material file, which among other things specifies that the decal should be drawn with a polygon offset of 1, meaning it should be drawn a little bit in front of where you place the decal. That's to stop z-fighting when you place a decal exactly on a wall.

This a common well-documented OpenGL technique, recommended for this exact purpose and it seems reliable -- I can't find other people with the same problem by googling, for example.

In the engine, two cvars are used to control the amount of depth offset, and for one of them (r_offsetUnits) we seem to have a default value that's 600 times the recommended value. That could be why we're getting way too much overdraw. The other (r_offsetFactor) we have set to 0, which is the recommended value for a small constant offset if you're looking fairly flat-on to your decal. It recommends tweaking it to 0.75 or 1 if you get problems when looking side-on.

The OpenGL docs talk about using a value of -1 for offsetUnits for a decal, but our default is -600. I tried setting it to -1 (leaving offsetFactor at 0) and it cures the hand problem in that video. I also tried running round a bit in Business as Usual (I knew I'd find plenty of decals in one of Biker's maps :) ) and it not only cures decals on windows and doors, it removes the same glitch on thick walls like the one in the vid below.

Could people try this out when playing please? If it works for everyone we can change the default.

r_offsetUnits -1

I find that works ok for me even when looking side on, at least in the examples I've looked at so far. If you do see any z-fighting decals side-on then you can also try

r_offsetFactor -0.75

But it seems to work fine for me at all angles with just the first fix.
//
SteveL

SteveL

08.02.2015 01:30

developer   ~0007411

Various situatioons discussed in the thread: http://forums.thedarkmod.com/topic/16922-decals-drawing-over-stuff/

We need to find some parameters that work everywhere.
SteveL

SteveL

17.05.2015 10:31

developer   ~0007515

Added archive flags to the cvars so they can persist between sessions

at rev 6496
/trunk/renderer/RenderSystem_init.cpp
SteveL

SteveL

12.10.2015 00:57

developer   ~0007857

Set the defaults to -0.1 / -1 as discussed here: http://forums.thedarkmod.com/topic/17394-prologue-performance-mystery/page-3#entry379538
SteveL

SteveL

12.10.2015 19:06

developer   ~0007862

Last edited: 12.10.2015 19:08

View 2 revisions

committed at rev 14404
autoexec.cfg

And (code) rev 6550
/renderer/RenderSystem_init.cpp

plus binaries

SteveL

SteveL

13.10.2015 13:29

developer   ~0007863

Unresolving while we fiddle with the numbers.
SteveL

SteveL

08.01.2016 19:36

developer   ~0008009

Made new dev forum post to gather people's latest settings for 2.04.
SteveL

SteveL

06.02.2016 11:26

developer   ~0008039

At rev 6575
/renderer/RenderSystem_init.cpp

Set the values to those suggested by empirical testing, even if setting r_offsetFactor to -0.1 doesn't make any sense based on the theory I read.

Removed the settings from autoexec.cfg

Issue History

Date Modified Username Field Change
05.02.2015 12:12 SteveL New Issue
05.02.2015 12:12 SteveL Status new => assigned
05.02.2015 12:12 SteveL Assigned To => SteveL
05.02.2015 12:16 SteveL Note Added: 0007404
05.02.2015 19:39 Springheel Note Added: 0007405
07.02.2015 04:37 SteveL Note Added: 0007406
07.02.2015 05:11 SteveL Note Added: 0007409
08.02.2015 01:30 SteveL Note Added: 0007411
17.05.2015 10:31 SteveL Note Added: 0007515
12.10.2015 00:57 SteveL Note Added: 0007857
12.10.2015 19:06 SteveL Note Added: 0007862
12.10.2015 19:08 SteveL Note Edited: 0007862 View Revisions
12.10.2015 19:08 SteveL Status assigned => resolved
12.10.2015 19:08 SteveL Fixed in Version => TDM 2.04
12.10.2015 19:08 SteveL Resolution open => fixed
13.10.2015 13:29 SteveL Note Added: 0007863
13.10.2015 13:29 SteveL Status resolved => assigned
08.01.2016 19:36 SteveL Note Added: 0008009
06.02.2016 11:26 SteveL Note Added: 0008039
06.02.2016 11:27 SteveL Status assigned => resolved
31.12.2017 07:24 stgatilov Relationship added related to 0004634