[SOLVED] Distant geometry renders in front of closer geometry

[MirceaKitsune 162]

Hello. I am experiencing a strange issue with the 3D viewport in DarkRadiant; Distant geometry cuts through closer geometry, causing some surfaces and objects to show in front of those closer than them to the camera. Has anyone else gotten this glitch, and does anyone know how to fix it? I'm running latest GIT master of DarkRadiant. A screenshot of the problem:

 

 

 

 

 

 

[EDIT] The cause of the issue was at last found and a patch was posted. See this post for more details.

Edited October 5, 2015 by MirceaKitsune

[SeriousToni 453]

You shouldn't forget to post your system and hardware infos too ^^

[MirceaKitsune 162]

You shouldn't forget to post your system and hardware infos too ^^

Sorry about that: Linux openSUSE 13.2 x64. ATI Radeon HD 6870. MESA 10.3.0, Gallium 0.4 on AMD BARTS.

[PrinzEnrique 4]

same problem here ... at least i think

 

running on Gentoo Linux

tried with both 2.0.1 and 2.0.2

 

OpenGL renderer string: Mesa DRI Intel® Haswell Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.8

 

no gallium at all

Edited January 13, 2015 by PrinzEnrique

[7318 10]

same problem for me, since the transition to wx

[hypov8 1]

i had the same issue.

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?

[7318 10]

but in linux there are no *.dll files

[MirceaKitsune 162]

Still hoping for a solution to this. It's the primary reason why I can't attempt any mission making for TDM right now, alongside a few broken menus.

 

I agree this is likely related to transparency. OpenGL is known for having issues with sorting multiple transparent surfaces. The strange thing is that this happens for non-transparent materials as well.

 

Sadly I don't know how to hack binaries. Especially on Linux, where there are indeed no dll files.

 

As a quick workaround, I would suggest adding an option to disable transparency in the 3D view altogether. Which I think is a preference many users might want to have either way (eg: on slower graphics cards).

[MirceaKitsune 162]

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?

[SteveL 1042]

Can you use version 1.8.1 (July 2014) as a workaround, until this issue gets dealt with? DR hasn't diverged, and maps are fully compatible across the versions. And you'll still have access to the latest TDM 2.03 assets. They are not part of DR, so it doesn't matter which version you use.

[hypov8 1]

you still have not made a workaround??

what about editing the shaders, renaming translucent?

noetpad++ will rename all of then files with find/replace

[motorsep 36]

Simple workaround - install Windows 7 64bit and be happy.

[MirceaKitsune 162]

Simple workaround - install Windows 7 64bit and be happy.

 

No, thank you... I am very happy with my openSUSE 13.2 x64

 

Like I said, I think the easiest workaround to quickly solve this problem would be an option to disable all and any transparency in the 3D viewport... even if the setting is not present in the menu and can be manually added to the Darkradiant configuration file. Someday afterwards, the issue can hopefully be fixed at its core so transparency can be enabled without it happening. I just hope someone will look into this at all soon...

[motorsep 36]

Install different driver maybe?

 

It's funny that even on Blender, you don't go around making devs to spend time and make it work on obsolete hardware - you buy new hardware than can handle Blender. Even switch OS if you have to. I am not even talking about Unreal Engine 4, Unity, Maya, etc.

[MirceaKitsune 162]

Install different driver maybe?

 

It's funny that even on Blender, you don't go around making devs to spend time and make it work on obsolete hardware - you buy new hardware than can handle Blender. Even switch OS if you have to. I am not even talking about Unreal Engine 4, Unity, Maya, etc.

 

I have good and modern hardware actually... the Radeon 6870 is seriously not that old. I use the video driver provided by Linux (MESA / Gallium / AMD Barts), and no I'm not getting the proprietary one which for Linux sucks. Lastly, I'm not putting a gun to any developer's head and making them do anything, although I am kindly asking that this is something they address somehow as it is a major bug. Also, as it can be seen above, there are other people who reported having this problem, so this time I'm at least not the only one.

[hypov8 1]

 

The strange thing is that this happens for non-transparent materials as well.

 

 

i didnt notice this comment before.

this is not the same issue i get , seems like a lynix/driver issue.

wonder how many lynix versions have been downloaded without the same issue?

 

they have made a big move to msv 2013 and wx. your os is probly the last thing on the dev's mind.

 

if old versions work, use them.. or like ppl sugest. get windows. dual boot/emulator etc if u want to map for now, untill its looked into?

check console to see if its useing the on board intel? maybe try another video card, geforce? a gfx tweaker?

if you can build the git, then try rename a common shader atribute that is causing the issue eg. areaportal, translucent

 

report your finds. it may help you and there development

Edited April 6, 2015 by hypov8

[MirceaKitsune 162]

Still happens with the latest DarkRadiant from GIT, even with a development version of Mesa 10.7 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. And no... please don't suggest changing my OS over this, or hunting for ancient versions of DR which likely won't even compile on my system.

 

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. Anyone?

 

[EDIT] Someone else seems to have reported this or a similar problem recently: http://bugs.thedarkmod.com/view.php?id=4217

Edited September 27, 2015 by MirceaKitsune

[Bikerdude 3738]

You could use PlayOnLinux and run DR inside that, speak to Freyk, he and I have been working on the mac version PlayOnmac where I have gotten the windows version of TDM running on OSX.

[MirceaKitsune 162]

You could use PlayOnLinux and run DR inside that, speak to Freyk, he and I have been working on the mac version PlayOnmac where I have gotten the windows version of TDM running on OSX.

 

As non-optimal and counter intuitive as this feels at first, downloading the Windows version and running it on Wine instead of using the native binary might actually be a workaround. I shall give this a try later and see if it runs then if the problem goes away with it.

[MirceaKitsune 162]

I installed DarkRadiant 2.0.2 from its download page inside Wine. As expected, it crashes at startup due to "unhandled exception" errors and the like. So running DR through Wine is not an option it seems.

[HMart 281]

Afaik idtech 4 uses OGL 1.5 render and if i would guess i would say DarkRadiant uses OGL 1.5 or above, so i ask, is mesa a full OpenGL 1.5+ supporting driver? Does it support all the necessary OGL extensions? If not your only way is to install the official AMD linux Driver, there's a new one available on the AMD site.

 

Here http://support.amd.com/en-us/kb-articles/Pages/AMDCatalyst15-9LINReleaseNotes.aspx

[MirceaKitsune 162]

Afaik idtech 4 uses OGL 1.5 render and if i would guess i would say DarkRadiant uses OGL 1.5 or above, so i ask, is mesa a full OpenGL 1.5+ supporting driver? Does it support all the necessary OGL extensions? If not your only way is to install the official AMD linux Driver, there's a new one available on the AMD site.

 

Here http://support.amd.com/en-us/kb-articles/Pages/AMDCatalyst15-9LINReleaseNotes.aspx

 

Sure... I wouldn't be able to play most games if it didn't. It now supports OpenGL 4.1, although in practice I only get up to OpenGL 3.3 due to limitations in the r600 driver.

[HMart 281]

Then i can only assume that this is a bug on the mesa driver and the only way is to wait for a mesa driver fix (but after 9 months they still didn't solved it? Perhaps people didn't reported the problem.), install the new AMD linux driver, i know you said it is bad but perhaps this new one works better? Just try it, doesn't hurt, and you can always go back (i think, at least on windows you can), or wait for TDM DarkRadiant coder to make a temporary fix or workaround, but if he still didn't made it, is because there's some important reason, that i don't know about.

[Bikerdude 3738]

I installed DarkRadiant 2.0.2 from its download page inside Wine. As expected, it crashes at startup due to "unhandled exception" errors and the like. So running DR through Wine is not an option it seems.

Give Freyk a PM, as I know he has got it working.

[MirceaKitsune 162]

Give Freyk a PM, as I know he has got it working.

 

Done, I will wait for his reply and try to run the Windows version on Wine again.

 

And please everyone, stop suggesting that I change my operating system or install a driver I don't want on my system! I mentioned I won't do that already: I use this machine for several things, including running other Linux games which work flawlessly through Mesa. I assume that if I installed fglrx, this problem would go away... but I don't want it on my system, and won't play with installing / uninstalling a driver which can easily break my OS.

 

And no, this doesn't mean it's necessarily something Mesa has to fix, nor that DarkRadiant did something stupid; It can simply be a line of code in DR that gets on Mesa's bad side, and which fewer Mesa users were around to notice until now. I'm willing to bet that adding a simple check somewhere in the DR rendering pipeline will solve the problem. I'm ready to test any solution, but need a suggestion from one of the developers as to what!

Edited September 28, 2015 by MirceaKitsune