View Issue Details

IDProjectCategoryView StatusLast Update
0004017DarkRadiantRendererpublic02.10.2017 12:12
ReporterMirceaKitsune Assigned To 
Status closedResolutionfixed 
Platformx64OSLinux openSUSEOS Version13.2
Fixed in Version2.0.3 
Summary0004017: Distant geometry renders in front of closer geometry (depth test fail)
DescriptionDistant geometry cuts through closer geometry in the 3D viewport, causing some surfaces and objects to show in front of those closer than them to the camera. This is most likely a problem with the Z-buffer.
Additional InformationLinux openSUSE 13.2 x64. ATI Radeon HD 6870. MESA 10.3.0, Gallium 0.4 on AMD BARTS. Running latest GIT master of DarkRadiant.

Forum thread:

FreeDesktop issue:
TagsNo tags attached.




05.01.2015 15:38


9th4eg.jpg (685,113 bytes)


14.01.2015 02:00

reporter   ~0007341

I don't mean to rush, but any thoughts on this please? The issue makes DarkRadiant unusable for creating any complex map, as it's impossible to understand and edit brushes and entities properly. Someone else was also able to confirm this on the forum thread:


27.01.2015 00:57

reporter   ~0007394

its seems to be caused by shaders with translucent set
my work around has been to hex edit the word to something else
eg.. tranzlucent

it might be some custome gfx settings we use?


26.03.2015 13:45

reporter   ~0007477

Any news on this issue? Nothing I tried so far solves it for me. I wish to get into Darkmod mission making, and this is the only serious reason why I cannot use DR at all. Can any fix, even a simple workaround for the time being, be added to GIT please?


27.09.2015 00:12

reporter   ~0007802

Still happens with the latest version of DarkRadiant from GIT, even with a development version of Mesa 10.7 which is newer than the one installed by my distribution. It's sad that after 9 months, I can't even find a sloppy workaround to this showstopper, and therefore can't attempt creating a TDM mission.

If other people can't replicate the bug or don't have the time / resources to test this in more depth, maybe someone can at least suggest lines of code that I can try to modify, where you think the problem is likely to reside? I'm willing to do part of the hunting for this bug, and certainly ready to test it anytime... I am not familiar with the source code of DR however and would need guidance from someone who is.


01.10.2015 20:08

reporter   ~0007828

Last edited: 01.10.2015 20:11

I ran an intensive series of tests on this problem, and produced the following notes:

- Commit:

Below is the oldest GIT commit I could test down to, in which I can confirm the problem already existed. Anything lower does not compile for me due to various reasons.

Commit: 967388dbed99ac820d1f2c34bceecd5334babacd
Tag: 2.0.1-1-trusty1
Date: 24-12-2014

- Mesa variable tests:

I tried to run DarkRadiant with various Mesa specific environment variables enabled. The full list is available here:

LIBGL_ALWAYS_INDIRECT: Crash when rendering.
LIBGL_ALWAYS_SOFTWARE: No change (only lower FPS).
MESA_NO_ASM: No change.
MESA_NO_MMX: No change.
MESA_NO_3DNOW: No change.
MESA_NO_SSE: No change.
MESA_TEX_PROG: No change.
MESA_TNL_PROG: No change.
RADEON_NO_TCL: No change.
DRAW_FSE: No change.
DRAW_NO_FSE: No change.
DRAW_USE_LLVM: No change.
MESA_EXTENSION_OVERRIDE: I tried to disable a few extensions having to do with depth, but no change.
MESA_GL_VERSION_OVERRIDE: Lower than 1.5 causes DarkRadiant to crash when rendering. Higher than 3.0 causes everything to stop rendering. Otherwise no change.

- Code tests:

I experimented with several changes in the code, which can be potentially tied to the issue. The files mentioned below are likely places where the issue might reside.

* OpenGLRenderSystem.cpp:

line 102: In function OpenGLRenderSystem::render, I commented out or reversed (eg: glDisable to glEnable) various GL environment options. Some changes would cause certain things to not render or the program to crash, but nothing fixed the issue.

line 191: Here, an iteration takes place which renders each OpenGL state. I initially suspected that different states might be ordered incorrectly, causing them to be displayed in a bad order. I hacked the function so I could see what was being rendered by each state: It appears that surfaces part of the same state render over each other as well, ruling out this possibility.

* OpenGLShader:

line 520 & 524: Commenting out these lines didn't solve the issue, but caused some entities to overlap others instead of being overlapped themselves, which might offer a clue about the nature of the problem. The lines are:

* OpenGLShaderPass.cpp:

line 612: As with line 191 from OpenGLRenderSystem.cpp, I hacked this iteration to see what was being rendered in each state. It appears that an incorrect order here is also ruled out, as geometry in the same state overlaps itself too.

- Other observations:

Changing any of the settings in the Preferences menu has no effect on the issue.

This issue exists for all view modes of the 3D viewport: Wireframe, Solid, Textured, Lighting.

This issue doesn't happen only in the 3D viewport, but also in the character viewer window (skin selector). This indicates it's a global issue with 3D rendering in DarkRadiant.

Faces that are part of the same model (eg: md5) can overlap each other as well. Meaning it's not just some objects overlapping others, but also rendering through themselves.

The issue is not related to backface culling! Back faces do not render in any case, only frontal faces as expected. Faces positioned behind other faces simply render through them, which is where we get the problem.

The issue is not exclusive to transparent shaders! Even on a map with just two brushes, both given a single solid texture, one brush will render in front of the other while behind it.

On some occasions, reloading materials causes the order of overlapping faces to change. So if you open the Textures tab and click the Reload Materials button, some objects will start to overlap while others will start being overlapped. Strangely enough, what you have selected while doing this can influence the result: If you reload the materials after you select a given brush, the pattern will change... then if you deselect everything back and reload again, it will return to the previous pattern.

Selection is not affected and works at the real depth. As in, an object might render through a wall, but shift-clicking it will select the wall instead. Selection boxes also render correctly and don't appear to be subject to the bug.

All objects are subject to cubic camera clipping, and will be correctly hidden by the far plane view.

Temporarily removing the GLSL shaders of DarkRadiant (the DarkRadiant/share/darkradiant/gl directory) had no effect.

From the information I could gather, what's happening is a bug with the depth buffer (z-buffer). It could even be an odd form of z-fighting! If you do an image search on depth buffer problems, you'll find several screenshots similar to this.



05.10.2015 18:48


FixDepthBuffer.diff (674 bytes)   
diff --git a/libs/wxutil/GLWidget.cpp b/libs/wxutil/GLWidget.cpp
index fab5b91..85d50b6 100644
--- a/libs/wxutil/GLWidget.cpp
+++ b/libs/wxutil/GLWidget.cpp
@@ -8,8 +8,14 @@
 namespace wxutil
+int attribs [] = {
 GLWidget::GLWidget(wxWindow *parent, const std::function<void()>& renderCallback, const std::string& name) :
-	wxGLCanvas(parent, -1, (int*)NULL, wxDefaultPosition, wxDefaultSize,
+	wxGLCanvas(parent, -1, attribs, wxDefaultPosition, wxDefaultSize,
 	wxFULL_REPAINT_ON_RESIZE | wxWANTS_CHARS, wxString(name.c_str(), *wxConvCurrent)),
FixDepthBuffer.diff (674 bytes)   


05.10.2015 18:51

reporter   ~0007841

The cause of the issue has been at last found, thanks to a suggestion by OrbWeaver. It was triggered by initializing the WX OpenGL canvas without any attributes, which caused Mesa to assume no depth buffer at all. I attached a patch which fixes this, by correctly initializing it with a set of standard parameters.


09.10.2015 16:25

reporter   ~0007844

Problem fixed in the GIT repositories (OrbWeaver and CodeReader). Thanks for the support everyone! This report can be closed as solved now.


01.10.2017 23:18

reporter   ~0009373

Last edited: 01.10.2017 23:19

This issue can now be marked as resolved: I have not seen it again in nearly two years. As I cannot set my own tickets to resolved, I thought I'd bump this so the developers can close it.



02.10.2017 12:12

administrator   ~0009375


Issue History

Date Modified Username Field Change
05.01.2015 15:38 MirceaKitsune New Issue
05.01.2015 15:38 MirceaKitsune File Added: 9th4eg.jpg
06.01.2015 06:17 greebo Status new => acknowledged
14.01.2015 02:00 MirceaKitsune Note Added: 0007341
27.01.2015 00:57 hypov8 Note Added: 0007394
26.03.2015 13:45 MirceaKitsune Note Added: 0007477
27.09.2015 00:12 MirceaKitsune Note Added: 0007802
01.10.2015 20:08 MirceaKitsune Note Added: 0007828
01.10.2015 20:08 MirceaKitsune Description Updated
01.10.2015 20:08 MirceaKitsune Additional Information Updated
01.10.2015 20:11 MirceaKitsune Additional Information Updated
01.10.2015 20:11 MirceaKitsune Note Edited: 0007828
05.10.2015 14:19 MirceaKitsune Summary Distant geometry renders in front of closer geometry => Distant geometry renders in front of closer geometry (depth test fail)
05.10.2015 14:19 MirceaKitsune Additional Information Updated
05.10.2015 18:48 MirceaKitsune File Added: FixDepthBuffer.diff
05.10.2015 18:51 MirceaKitsune Note Added: 0007841
09.10.2015 16:25 MirceaKitsune Note Added: 0007844
01.10.2017 23:18 MirceaKitsune Note Added: 0009373
01.10.2017 23:19 MirceaKitsune Note Edited: 0009373
02.10.2017 12:12 greebo Note Added: 0009375
02.10.2017 12:12 greebo Status acknowledged => closed
02.10.2017 12:12 greebo Resolution open => fixed
02.10.2017 12:12 greebo Fixed in Version => 2.0.3