 |
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: http://forums.thedarkmod.com/topic/16848-distant-geometry-renders-in-front-of-closer-geometry/?p=363389 |
 |
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 darkradiant\modules\shaders.dll it might be some custome gfx settings we use? |
|
|
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? |
|
|
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. |
|
|
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: http://www.mesa3d.org/envvars.html LIBGL_ALWAYS_INDIRECT: Crash when rendering. LIBGL_ALWAYS_SOFTWARE: No change (only lower FPS). LIBGL_NO_DRAWARRAYS: No change. LIBGL_DRI3_DISABLE: No change. 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: previewPass.setSortPosition(OpenGLState::SORT_OVERLAY_FIRST); previewPass.setSortPosition(OpenGLState::SORT_FULLBRIGHT); * 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. |
|
|
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. |
|
|
Problem fixed in the GIT repositories (OrbWeaver and CodeReader). Thanks for the support everyone! This report can be closed as solved now. |
|
|
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. |
 |
Thanks |
- Anonymous
