Jump to content
The Dark Mod Forums
Sign in to follow this  
MirceaKitsune

[SOLVED] Distant geometry renders in front of closer geometry

Recommended Posts

And please everyone, stop suggesting that I change my operating system or install a driver I don't want on my system! ... installing / uninstalling a driver which can easily break my OS.

My suggestion is also to install a video driver, because running DR on wine is not the sollution.

In theory its possible you get the same graphical issues and when youre are using my pol-script at the moment DR crashes when you load or create a map,

But you all invited to help me to improve the pol-script.

 

And if you are afraid to break your os, just make a system backup (using, for example, clonezilla) before the driver installation.

Edited by freyk

Share this post


Link to post
Share on other sites

Yes, running DarkRadiant on WINE will obviously not happen :( I took a look at that thread and read your PM, and installed everything you mentioned via Winetricks. Also tried both the 32bit and 64bit versions, same story with both. This is the crash log:

mircea@linux-qz0r:~/WINE drive/Program Files/DarkRadiant> wine ./DarkRadiant
fixme:service:scmdatabase_autostart_services Auto-start service L"SecDrv" failed to start: 2
fixme:ntoskrnl:MmGetSystemRoutineAddress L"KdRefreshDebuggerNotPresent" not found
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
fixme:heap:RtlSetHeapInformation 0x1270000 0 0x23fcf0 4 stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23f800 1 C) semi-stub
fixme:system:SetProcessDPIAware stub!
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23e620 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23e240 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23f380 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23f200 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23ef70 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23ee00 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23f1b0 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23ec70 1 C) semi-stub
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23d760 1 C) semi-stub
fixme:commctrl:TaskDialogIndirect 0x23d190, 0x23d140, (nil), (nil)
fixme:commctrl:TaskDialogIndirect dwCommonButtons=6 uType=4 ret=6
fixme:commctrl:TaskDialogIndirect 0x23d190, 0x23d140, (nil), (nil)
fixme:commctrl:TaskDialogIndirect dwCommonButtons=6 uType=4 ret=6
fixme:commctrl:TaskDialogIndirect 0x23d190, 0x23d140, (nil), (nil)
fixme:commctrl:TaskDialogIndirect dwCommonButtons=6 uType=4 ret=6
fixme:commctrl:TaskDialogIndirect 0x23d190, 0x23d140, (nil), (nil)
fixme:commctrl:TaskDialogIndirect dwCommonButtons=6 uType=4 ret=7
fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x23d6a0 1 C) semi-stub
fixme:seh:__CxxFrameHandler 0x23d6e0 23d980 0x23c6c0 0x23c590: not implemented
fixme:seh:__CxxFrameHandler 0x23d6e0 23fba0 0x23c6c0 0x23c590: not implemented
fixme:seh:__CxxFrameHandler 0x23d6e0 23fc90 0x23c6c0 0x23c590: not implemented
wine: Unhandled exception 0xe06d7363 in thread 2a at address 0x7b84b8a1 (thread 002a), starting debugger...
Unhandled exception: C++ exception(object = 0x0023d900, type = 0x017ef818) in 64-bit code (0x000000007b84b8a1).
fixme:dbghelp:interpret_function_table_entry PUSH_MACHFRAME 6
fixme:dbghelp:interpret_function_table_entry PUSH_MACHFRAME 6
Register dump:
 rip:000000007b84b8a1 rsp:000000000023d6c0 rbp:000000000023d919 eflags:00000206 (   - --  I   - -P- )
 rax:000000000023d700 rbx:000000000023d6e0 rcx:000000000023d6e0 rdx:0000000000000018
 rsi:000000000023d860 rdi:000000000023d700  r8:0000000000000003  r9:000000000023d860 r10:0000000000000002
 r11:00007f4f88eb5bd0 r12:00007fffff7ef000 r13:0000000000000000 r14:00000000011cb8c0 r15:00000000011cb8d0
Stack dump:
0x000000000023d6c0:  000000000023d6e0 0000000000000000
0x000000000023d6d0:  0000000000000000 0000000000000000
0x000000000023d6e0:  00000001e06d7363 0000000000000000                                                                                                
0x000000000023d6f0:  000000007b84b8a1 0000000000000003                                                                                                
0x000000000023d700:  0000000019930520 000000000023d900                                                                                                
0x000000000023d710:  00000000017ef818 00000000ffffff00                                                                                                
0x000000000023d720:  0000000000000000 0000000000000000                                                                                                
0x000000000023d730:  0000000000000000 0000000000000000                                                                                                
0x000000000023d740:  0000000000000000 0000000000000000
0x000000000023d750:  0000000000000000 0000000000000000
0x000000000023d760:  000000000023d900 0000000000000000
0x000000000023d770:  00000000011cbdc0 00007f4f84a5c7a4
Backtrace:
=>0 0x000000007b84b8a1 RaiseException+0xa1() in kernel32 (0x000000000023d919)
  1 0x00007f4f84a5f951 _CxxThrowException+0x30() in msvcr120 (0x000000000023d919)
  2 0x00000000017d522c in vfspk3 (+0x522b) (0x000000000023d919)
  3 0x00000000017d58b7 in vfspk3 (+0x58b6) (0x000000000023dbc0)
  4 0x00000000017d5f0e in vfspk3 (+0x5f0d) (0x000000000023dbc0)
  5 0x0000000140103cc3 in darkradiant (+0x103cc2) (0x000000000023dcf0)
0x000000007b84b8a1 RaiseException+0xa1 in kernel32: 
Modules:
Module  Address                                 Debug info      Name (156 modules)
PE                240000-          287000       Deferred        glew32
PE                290000-          44e000       Deferred        libxml2-vc120
PE                450000-          467000       Deferred        libsigc++-vc120
PE                470000-          6db000       Deferred        wxbase30u_vc120_x64
PE                6e0000-          cb4000       Deferred        wxmsw30u_core_vc120_x64
PE                cc0000-          e46000       Deferred        wxmsw30u_adv_vc120_x64
PE                e50000-          e67000       Deferred        wxmsw30u_gl_vc120_x64
PE                e70000-          f40000       Deferred        wxmsw30u_xrc_vc120_x64
PE                f40000-          ff5000       Deferred        wxmsw30u_html_vc120_x64
PE               1000000-         102f000       Deferred        wxbase30u_xml_vc120_x64
PE               1030000-         1160000       Deferred        wxmsw30u_stc_vc120_x64
PE               1490000-         14c4000       Deferred        eventmanager
PE               14d0000-         1512000       Deferred        filters
PE               1520000-         155f000       Deferred        fonts
PE               1560000-         157e000       Deferred        commandsystem
PE               1580000-         1598000       Deferred        xmlregistry
PE               1610000-         1699000       Deferred        entity
PE               16a0000-         1787000       Deferred        particles
PE               1790000-         17aa000       Deferred        archivezip
PE               17b0000-         17c5000       Deferred        grid
PE               17d0000-         17f8000       Export          vfspk3
PE               1800000-         1838000       Deferred        md5model
PE               1840000-         187e000       Deferred        entitylist
PE               1880000-         1909000       Deferred        uimanager
PE               1910000-         1924000       Deferred        skins
PE               1930000-         19c9000       Deferred        mapdoom3
PE               19d0000-         1a2e000       Deferred        shaders
PE               1a30000-         1a63000       Deferred        eclassmgr
PE               1a70000-         1a85000       Deferred        scenegraph
PE               1a90000-         1aaa000       Deferred        image
PE               1ab0000-         1af7000       Deferred        sound
PE               1b00000-         1b16000       Deferred        undo
PE               1b20000-         1b2f000       Deferred        filetypes
PE               1b30000-         1b70000       Deferred        model
PE               1b70000-         1bc1000       Deferred        dm.difficulty
PE               1bd0000-         1ca6000       Deferred        dm.objectives
PE               1cb0000-         1d43000       Deferred        dm.conversation
PE               1d50000-         1d85000       Deferred        eclasstree
PE               1d90000-         1da3000       Deferred        wavefront
PE               1db0000-         1e78000       Deferred        dm.editing
PE               1e80000-         1f43000       Deferred        dm.stimresponse
PE               1f50000-         2005000       Deferred        dm.gui
PE               2010000-         2172000       Deferred        script
PE              1e000000-        1e2b0000       Deferred        python26
ELF             7a800000-        7abd8000       Deferred        opengl32<elf>
  \-PE          7a850000-        7abd8000       \               opengl32
ELF             7b800000-        7bc7f000       Dwarf           kernel32<elf>
  \-PE          7b820000-        7bc7f000       \               kernel32
ELF             7be00000-        7c103000       Deferred        <wine-loader>
PE             140000000-       140415000       Export          darkradiant
PE             180000000-       1800bf000       Deferred        ftgl-vc120
ELF         7f4f7cf6a000-    7f4f7d1b3000       Deferred        usp10<elf>
  \-PE      7f4f7cf70000-    7f4f7d1b3000       \               usp10
ELF         7f4f7d1b3000-    7f4f7d489000       Deferred        msvcr90<elf>
  \-PE      7f4f7d1d0000-    7f4f7d489000       \               msvcr90
ELF         7f4f7d489000-    7f4f7d691000       Deferred        librt.so.1
ELF         7f4f7d691000-    7f4f7d8ea000       Deferred        libopenal.so.1
ELF         7f4f7d92c000-    7f4f7db51000       Deferred        openal32<elf>
  \-PE      7f4f7d940000-    7f4f7db51000       \               openal32
ELF         7f4f7dc07000-    7f4f7de12000       Deferred        libnss_files.so.2
ELF         7f4f7de12000-    7f4f7e01e000       Deferred        libnss_nis.so.2
ELF         7f4f7e01e000-    7f4f7e236000       Deferred        libnsl.so.1
ELF         7f4f7e236000-    7f4f7e43e000       Deferred        libnss_compat.so.2
ELF         7f4f7e43e000-    7f4f7e6aa000       Deferred        libpcre.so.1
ELF         7f4f7e6aa000-    7f4f7e8ce000       Deferred        libselinux.so.1
ELF         7f4f7e8ce000-    7f4f7eae5000       Deferred        libresolv.so.2
ELF         7f4f7eae5000-    7f4f7ece9000       Deferred        libkeyutils.so.1
ELF         7f4f7ece9000-    7f4f7eef6000       Deferred        libkrb5support.so.0
ELF         7f4f7eef6000-    7f4f7f0fa000       Deferred        libcom_err.so.2
ELF         7f4f7f0fa000-    7f4f7f32a000       Deferred        libk5crypto.so.3
ELF         7f4f7f32a000-    7f4f7f5fb000       Deferred        libkrb5.so.3
ELF         7f4f7f5fb000-    7f4f7fa1e000       Deferred        libcrypto.so.1.0.0
ELF         7f4f7fa1e000-    7f4f7fc85000       Deferred        libssl.so.1.0.0
ELF         7f4f7fc85000-    7f4f7fecd000       Deferred        libgssapi_krb5.so.2
ELF         7f4f7fecd000-    7f4f80124000       Deferred        libcups.so.2
ELF         7f4f80124000-    7f4f80360000       Deferred        uxtheme<elf>
  \-PE      7f4f80130000-    7f4f80360000       \               uxtheme
ELF         7f4f80360000-    7f4f8056b000       Deferred        libxcursor.so.1
ELF         7f4f8056b000-    7f4f8077b000       Deferred        libxi.so.6
ELF         7f4f8077b000-    7f4f8097e000       Deferred        libxcomposite.so.1
ELF         7f4f8097e000-    7f4f80b88000       Deferred        libxrandr.so.2
ELF         7f4f80b88000-    7f4f80d92000       Deferred        libxrender.so.1
ELF         7f4f80d92000-    7f4f80f95000       Deferred        libxinerama.so.1
ELF         7f4f80fd7000-    7f4f81273000       Deferred        winex11<elf>
  \-PE      7f4f80ff0000-    7f4f81273000       \               winex11
ELF         7f4f81273000-    7f4f8149a000       Deferred        imm32<elf>
  \-PE      7f4f81280000-    7f4f8149a000       \               imm32
ELF         7f4f815cb000-    7f4f81809000       Deferred        libfontconfig.so.1
ELF         7f4f81809000-    7f4f81a46000       Deferred        libpng16.so.16
ELF         7f4f81a46000-    7f4f81c5c000       Deferred        libz.so.1
ELF         7f4f81c5c000-    7f4f81ef3000       Deferred        libfreetype.so.6
ELF         7f4f81ef3000-    7f4f82127000       Deferred        libtinfo.so.5
ELF         7f4f82127000-    7f4f8234f000       Deferred        libncurses.so.5
ELF         7f4f8234f000-    7f4f8257b000       Deferred        msacm32<elf>
  \-PE      7f4f82360000-    7f4f8257b000       \               msacm32
ELF         7f4f8257b000-    7f4f8283c000       Deferred        winmm<elf>
  \-PE      7f4f82580000-    7f4f8283c000       \               winmm
ELF         7f4f8283c000-    7f4f82bc4000       Deferred        oleaut32<elf>
  \-PE      7f4f82860000-    7f4f82bc4000       \               oleaut32
ELF         7f4f82bc4000-    7f4f82e0b000       Deferred        winspool<elf>
  \-PE      7f4f82bd0000-    7f4f82e0b000       \               winspool
ELF         7f4f82e0b000-    7f4f83111000       Deferred        comctl32<elf>
  \-PE      7f4f82e20000-    7f4f83111000       \               comctl32
ELF         7f4f83111000-    7f4f83403000       Deferred        comdlg32<elf>
  \-PE      7f4f83120000-    7f4f83403000       \               comdlg32
ELF         7f4f83403000-    7f4f83698000       Deferred        rpcrt4<elf>
  \-PE      7f4f83410000-    7f4f83698000       \               rpcrt4
ELF         7f4f83698000-    7f4f83a19000       Deferred        ole32<elf>
  \-PE      7f4f836c0000-    7f4f83a19000       \               ole32
ELF         7f4f83a19000-    7f4f83ca8000       Deferred        shlwapi<elf>
  \-PE      7f4f83a30000-    7f4f83ca8000       \               shlwapi
ELF         7f4f83ca8000-    7f4f84123000       Deferred        shell32<elf>
  \-PE      7f4f83cc0000-    7f4f84123000       \               shell32
ELF         7f4f84123000-    7f4f8433d000       Deferred        version<elf>
  \-PE      7f4f84130000-    7f4f8433d000       \               version
ELF         7f4f8433d000-    7f4f846dd000       Deferred        user32<elf>
  \-PE      7f4f84360000-    7f4f846dd000       \               user32
ELF         7f4f846dd000-    7f4f84a1b000       Deferred        msvcp120<elf>
  \-PE      7f4f84720000-    7f4f84a1b000       \               msvcp120
ELF         7f4f84a1b000-    7f4f84d0a000       Dwarf           msvcr120<elf>
  \-PE      7f4f84a40000-    7f4f84d0a000       \               msvcr120
ELF         7f4f84d0a000-    7f4f84f0e000       Deferred        libxau.so.6
ELF         7f4f84f0e000-    7f4f8511a000       Deferred        libdrm.so.2
ELF         7f4f8511a000-    7f4f85320000       Deferred        libxxf86vm.so.1
ELF         7f4f85320000-    7f4f85523000       Deferred        libxshmfence.so.1
ELF         7f4f85523000-    7f4f85743000       Deferred        libxcb.so.1
ELF         7f4f85743000-    7f4f85949000       Deferred        libxcb-sync.so.1
ELF         7f4f85949000-    7f4f85b4c000       Deferred        libxcb-present.so.0
ELF         7f4f85b4c000-    7f4f85d4f000       Deferred        libxcb-dri3.so.0
ELF         7f4f85d4f000-    7f4f85f54000       Deferred        libxcb-dri2.so.0
ELF         7f4f85f54000-    7f4f8616c000       Deferred        libxcb-glx.so.0
ELF         7f4f8616c000-    7f4f864aa000       Deferred        libx11.so.6
ELF         7f4f864aa000-    7f4f866ac000       Deferred        libx11-xcb.so.1
ELF         7f4f866ac000-    7f4f868b2000       Deferred        libxfixes.so.3
ELF         7f4f868b2000-    7f4f86ab5000       Deferred        libxdamage.so.1
ELF         7f4f86ab5000-    7f4f86cc7000       Deferred        libxext.so.6
ELF         7f4f86cc7000-    7f4f86ef1000       Deferred        libglapi.so.0
ELF         7f4f86ef1000-    7f4f8711b000       Deferred        libexpat.so.1
ELF         7f4f87423000-    7f4f876b3000       Deferred        libgl.so.1
ELF         7f4f876b3000-    7f4f87932000       Deferred        libglu.so.1
ELF         7f4f87974000-    7f4f87b8e000       Deferred        glu32<elf>
  \-PE      7f4f87980000-    7f4f87b8e000       \               glu32
ELF         7f4f87b8e000-    7f4f87ef0000       Deferred        gdi32<elf>
  \-PE      7f4f87ba0000-    7f4f87ef0000       \               gdi32
ELF         7f4f87ef0000-    7f4f8817f000       Deferred        advapi32<elf>
  \-PE      7f4f87f00000-    7f4f8817f000       \               advapi32
ELF         7f4f88323000-    7f4f8853a000       Deferred        libgcc_s.so.1
ELF         7f4f8853a000-    7f4f8883b000       Deferred        libm.so.6
ELF         7f4f8883b000-    7f4f88b44000       Deferred        ntdll<elf>
  \-PE      7f4f88860000-    7f4f88b44000       \               ntdll
ELF         7f4f88b47000-    7f4f88d4b000       Deferred        libdl.so.2
ELF         7f4f88d4b000-    7f4f890f2000       Deferred        libc.so.6
ELF         7f4f890f2000-    7f4f8930f000       Deferred        libpthread.so.0
ELF         7f4f89352000-    7f4f896f7000       Dwarf           libwine.so.1
ELF         7f4f896f8000-    7f4f8991b000       Deferred        ld-linux-x86-64.so.2
ELF         7ffca1bf3000-    7ffca1bf5000       Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
0000000e services.exe
        00000024    0
        00000023    0
        0000001d    0
        00000014    0
        00000010    0
        0000000f    0
00000012 winedevice.exe
        0000001c    0
        00000019    0
        00000018    0
        00000013    0
0000001a plugplay.exe
        00000020    0
        0000001f    0
        0000001b    0
00000021 winedevice.exe
        00000026    0
        00000025    0
        00000022    0
00000027 explorer.exe
        0000002d    0
        0000002c    0
        0000002b    0
        00000028    0
00000029 (D) C:\Program Files\DarkRadiant\DarkRadiant.exe
        0000002a    0 <==
System information:
    Wine build: wine-1.7.51
    Platform: x86_64
    Host system: Linux
    Host version: 3.16.7-24-desktop
mircea@linux-qz0r:~/WINE drive/Program Files/DarkRadiant> 

As for the proprietary driver, this is the latest update on that.

Edited by MirceaKitsune

Share this post


Link to post
Share on other sites

Ok: I'm putting together a list of remaining alternatives and possible workarounds, while waiting for someone to suggest fixes in DR code. The last things that still come to mind are:

 

1 - A solution proposed a while ago was running DR 1.8.1, which was the last GTK version before the port to wxWidgets. I might actually try that... but I cannot find the source code for 1.8.1 anywhere, nor details on how I would compile it. Anyone got more info on this?

 

2 - Using a different gtkRadiant fork... particularly netRadiant which is actively maintained in Xonotic. The problem is, obviously, that it was designed for idTech <= 3, so I'm not sure it even uses the same map format! I could perhaps design the geometry in netRadiant then compile the map in DarkRadiant... but that's starting to look like more trouble than it's worth. Still, does anyone have an idea whether I could design TDM maps in another gtkRadiant fork for the time being?

 

3 - Temporarily hacking all shader files in TDM to remove transparency. Some people mentioned that it might solve the issue, and since this looks a lot like the notorious "OpenGL alpha sorting bug" I'm inclined to agree. Problem is how to automate the process for all shaders in all pk4 files, but in a temporary location to not break the actual game. Perhaps there's a shell script I can look to?

Share this post


Link to post
Share on other sites

I apologize for the triple post. During the last days I spent a lot of time debugging the problem, even testing changes in the DarkRadiant code and attempting a GIT bisect. I couldn't find a solution, but found a few clues and preformed a load of tests, which will certainly be helpful to finding the cause. If you're a developer, please take a look at this list when you have a minute!

 

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

 

Some example images from other engines below. In all cases, it's described as an application problem when programming the depth buffer.

 

 

57fVg.png

depth-buffer-disabled.png

Zbuff.png

 

Edited by MirceaKitsune
  • Like 1

Share this post


Link to post
Share on other sites

have you tested gtk radiant/netradiant yet. how is the objects rendering in that?

darkmod is a mod to doom 3. so most of its features are suported in gtk

 

instead of doing evry shader you could set up something in the parseBlendType blendFuncFromStrings to return null. no image/blends

do you know what stage types are causing the issue, like alpha blends, gl_one etc..

 

another area u can change

parseShaderFlags

if (token == "tranZlucent")

Edited by hypov8

Share this post


Link to post
Share on other sites

have you tested gtk radiant/netradiant yet. how is the objects rendering in that?

darkmod is a mod to doom 3. so most of its features are suported in gtk

 

instead of doing evry shader you could set up something in the parseBlendType blendFuncFromStrings to return null. no image/blends

do you know what stage types are causing the issue, like alpha blends, gl_one etc..

 

another area u can change

parseShaderFlags

if (token == "tranZlucent")

 

Yes, I use netRadiant with Xonotic. This issue does not exist there, nor in any other 3D renderer I've ran during my 3 years on Linux. But netRadiant is not intended to work with idTech 4... so how would I even get it to recognize TDM materials and entities, so I can see what textures I'm putting on brushes and where NPC's are located? If that's somehow possible, by all means do let me know how to do it!

 

And from the tests I posted about above, what I'm seeing is that it doesn't matter what type of shader it is. Even the "unknown shader" image will do this, which you can get by using DarkRadiant without selecting a game and engine path then drawing two brushes in the scene. I thought this was the old alpha sorting issue as well, but apparently it's something even weirder.

Share this post


Link to post
Share on other sites

maybe the problem is relative to this, quote from openGL faq

 

12.020 Depth buffering doesn't work in my perspective rendering. What's going on?

Make sure the
zNear
and
zFar
clipping planes are specified correctly in your calls to glFrustum() or gluPerspective().

A mistake many programmers make is to specify a
zNear
clipping plane value of 0.0 or a negative value which isn't allowed. Both the
zNear
and
zFar
clipping planes are positive (not zero or negative) values that represent distances in front of the eye.

Specifying a
zNear
clipping plane value of 0.0 to gluPerspective() won't generate an OpenGL error, but it might cause depth buffering to act as if it's disabled. A negative
zNear
or
zFar
clipping plane value would produce undesirable results.

A
zNear
or
zFar
clipping plane value of zero or negative, when passed to glFrustum(), will produce an error that you can retrieve by calling glGetError(). The function will then act as a no-op.

 

 

depth buffer in openGL is the same as the z-buffer.

 

https://www.opengl.org/archives/resources/faq/technical/depthbuffer.htm

Edited by stumpy

Share this post


Link to post
Share on other sites

@stumpy: Very useful article, thanks for sharing that! Strange thing is, I have no idea where zNear and zFar are determined in DarkRadiant, because neither glFrustum() nor gluPerspective() seem to be used throughout the code. The most suspect functions I found so far and edited in every possible way are: glBlendFunc(), glAlphaFunc(), glDepthFunc(), glPolygonOffset(), glTexEnvi().

 

Anyway, I was just doing more debugging while you replied, and was ready to take a break after several more hours spent on this (I'm also trying hard because I want the mystery uncovered). I just now became aware of an essential clue: Although in textured mode everything solid appears solid like it should, all textures are transparent in lighting preview mode! I initially ruled out the possibility of an alpha sorting issue, and concluded that depth testing simply stopped working altogether... this means I might have been wrong. Here's how solid stone and metal materials look like in lit mode:

 

2dlnqxe.png

 

I already went ahead and disabled transparency everywhere in the render code as a test. The result was bizarre: There were no longer any more transparent textures anywhere in the viewport, everything became opaque... in both textured and lit mode. But the depth issue continued to happen never the less! I'm pretty mind blown right now...

 

[EDIT 1] I found another thread where someone described the same issue, and posted a screenshot showing the exact same effect. It was with a specific texture however, whereas in this case it happens with absolutely all textures (even the default "shader not found"). It's described as an issue with transparency and blending modes, so that must be the place to keep looking.

 

[EDIT 2] I commented out all relevant functions I could find from plugins/shaders/*.cpp as well, or forced them to output opaque shaders. This even disabled image loading and turned off any transparency, but somehow the problem would still exist.

 

[EDIT 3] Found a potentially interesting clue: In OpenGLShader.cpp lines 367 & 368:

dbsPass.m_blend_src = GL_ONE;
dbsPass.m_blend_dst = GL_ONE;

If I turn the second GL_ONE into a GL_ZERO, solid materials no longer appear transparent in lighting preview mode, as they do in the screenshot above. Of course, the depth issue persists never the less.

Edited by MirceaKitsune

Share this post


Link to post
Share on other sites

Mother of god... frigging yes! After struggling with this for so long, I have at last gotten rid of this issue, and can finally run DR flawlessly and without any problems! :laugh:

 

I have not however found the solution to the original problem yet! Rather a workaround: A working GTK version of the latest DarkRadiant. OrbWeaver had the inspiration of reviving the GTK version of DR this September, which is now maintained on the gtk-legacy branch. I had to install a few weird dependencies, but I was able to compile it and can confirm it works fine.

 

I don't want to stop here however: I want to know why the wxWidgets version has this weird bug! I've created two copies of DarkRadiant on my drive, one for GTK and one for WX. I will stick to the GTK one for normal usage, and will use the WX repository to further test this issue.

 

As was pointed out to me in an earlier conversation, the most likely source is beginning to surface: A failing shader. OrbWeaver explained that GLSL is being used to do the depth buffering, which I was not aware of. Considering this only happens on Mesa, which is known to be more picky about shaders, the possibility seems very likely. Why only the wxWidgets version though?

Share this post


Link to post
Share on other sites

As OrbWeaver suggested, I took a look at the shaders in install/gl as well as the code that calls them (namely interaction_*.glsl and zfill_*.glsl). They cannot be the cause of the problem for one simple reason: They're only used in light preview mode! OpenGLShader.cpp, line 296, function OpenGLShader::appendInteractionLayer is where the depth fill program is fetched via getBuiltInProgram("depthFill"), the code doesn't care about it anywhere else. That function is only called when you're previewing lighting, handling the depth and bumpmap passes.

 

This clearly has very deep roots, that reach Mesa and / or wxWidgets. It is however triggered by something specific in DarkRadiant, and that something is what I think we should find out. I've already tried everything thinkable and unthinkable, but can't find where and how it's happening. So I'm waiting for more ideas and pointers if you have any!

 

In the meantime I filed a bug report with Mesa as well. You can follow it here:

 

http://bugs.freedesktop.org/show_bug.cgi?id=92286

Share this post


Link to post
Share on other sites

I thought in one of your earlier posts you said that the problem didn't affect the non-lit solid render mode, hence my suggestion to check the GLSL shader behaviour. If the problem occurs in both modes then the shaders cannot be the problem as you have correctly noted.

 

If the problem only occurs in wxWidgets but not GTK, this suggests that there is something about the way the GL widget is set up that triggers the issue. In fact, looking at the construction of the GLWidget in the following line:

 

https://gitlab.com/orbweaver/DarkRadiant/blob/master/libs/wxutil/GLWidget.cpp#L12

 

it seems that the wxGLCanvas is being passed NULL as its list of capability flags, which seems odd because this would imply that a depth buffer would never be created in any circumstances. Perhaps it is the case that all GL platforms other than Mesa provide a depth buffer by default, and therefore this issue is not seen in any environment. You could try changing this behaviour following the documentation here:

 

http://docs.wxwidgets.org/trunk/classwx_g_l_canvas.html#a56d0a2a022c0c34b7efa1114da151177

 

to construct a list of GL flags that includes a depth buffer size and see if this fixes the problem.

Share this post


Link to post
Share on other sites

... and that's it. The missing attributes in wxGLCanvas were the cause, I added them and now depth buffering works! Cheers again OrbWeaver :D This long ride has at last come to an end.

 

I've created a patch which properly initializes the WX context with standard parameters, using examples I found from other coders. Please test and commit it to the main branches... I'll be maintaining the change locally until then. The original patch file will be uploaded to the bug tracker as well, in case posting it here breaks its formatting.

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 [] = {
+	WX_GL_RGBA,
+	WX_GL_DOUBLEBUFFER,
+	WX_GL_DEPTH_SIZE, 16,
+};
+
 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)),
 	_registered(false),
 	_renderCallback(renderCallback),

  • Like 3

Share this post


Link to post
Share on other sites

Gratz on finding your fix and happy mapping!

 

Thank you! After how much time debugging this took, it's certainly a happy moment to have finally found the solution :)

Share this post


Link to post
Share on other sites

Excellent, thanks for the patch. I might consider adding a boolean constructor parameter to specify whether depth is needed, because it might not be needed in the 2D view renderers (but perhaps there is no advantage in turning it off even if the actual rendering doesn't use it). In any case your patch is a fine starting point and I'll do any refactoring locally on my end.

  • Like 2

Share this post


Link to post
Share on other sites

Excellent, thanks for the patch. I might consider adding a boolean constructor parameter to specify whether depth is needed, because it might not be needed in the 2D view renderers (but perhaps there is no advantage in turning it off even if the actual rendering doesn't use it). In any case your patch is a fine starting point and I'll do any refactoring locally on my end.

 

For the 2D viewports, it might still change the order in which the outlines of brushes and entities are drawn, which could be a minor annoyance for mappers attentive to detail. I'd leave it always on, that's simpler and I can't imagine it costing anything noticeable. I'm gladly ready to test the official patch for this, let me know when to GIT pull please.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...