View Issue Details

IDProjectCategoryView StatusLast Update
0004079The Dark ModGraphicspublic31.12.2017 07:24
ReporterSteveL Assigned ToSteveL  
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:

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.


related to 0004634 assignedstgatilov Decal depth fighting (Inn Business: "rug in tavern is not smooth") 




05.02.2015 12:16

reporter   ~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.


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.


07.02.2015 04:37

reporter   ~0007406

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


07.02.2015 05:11

reporter   ~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.


08.02.2015 01:30

reporter   ~0007411

Various situatioons discussed in the thread:

We need to find some parameters that work everywhere.


17.05.2015 10:31

reporter   ~0007515

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

at rev 6496


12.10.2015 00:57

reporter   ~0007857

Set the defaults to -0.1 / -1 as discussed here:


12.10.2015 19:06

reporter   ~0007862

Last edited: 12.10.2015 19:08

committed at rev 14404

And (code) rev 6550

plus binaries



13.10.2015 13:29

reporter   ~0007863

Unresolving while we fiddle with the numbers.


08.01.2016 19:36

reporter   ~0008009

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


06.02.2016 11:26

reporter   ~0008039

At rev 6575

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