View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004079||The Dark Mod||Graphics||public||05.02.2015 12:12||31.12.2017 07:24|
|Product Version||TDM 2.03|
|Target Version||TDM 2.04||Fixed in Version||TDM 2.04|
|Summary||0004079: Decals drawing over stuff in front|
|Description||From 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.
|Tags||No tags attached.|
|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.|
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.
|Ah, that's it. DECAL_MACRO in the dirt decals and some others hacks the depth of the surface.|
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.
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
But it seems to work fine for me at all angles with just the first fix.
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.
Added archive flags to the cvars so they can persist between sessions
at rev 6496
|Set the defaults to -0.1 / -1 as discussed here: http://forums.thedarkmod.com/topic/17394-prologue-performance-mystery/page-3#entry379538|
committed at rev 14404
And (code) rev 6550
|Unresolving while we fiddle with the numbers.|
|Made new dev forum post to gather people's latest settings for 2.04.|
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
|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|