 |
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. 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. // |
|
|
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 /trunk/renderer/RenderSystem_init.cpp |
|
|
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 autoexec.cfg And (code) rev 6550 /renderer/RenderSystem_init.cpp plus binaries |
|
|
Unresolving while we fiddle with the numbers. |
|
|
Made new dev forum post to gather people's latest settings for 2.04. |
|
|
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 |
- Anonymous
