freyk 432 Report post Posted September 28, 2015 (edited) 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 September 28, 2015 by freyk Quote Info: My portfolio and darkmod graphical installer Amnesty for Bikerdude! Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted September 28, 2015 (edited) 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 September 28, 2015 by MirceaKitsune Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted September 30, 2015 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? Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 1, 2015 (edited) 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: 967388dbed99ac820d1f2c34bceecd5334babacdTag: 2.0.1-1-trusty1Date: 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.htmlLIBGL_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. Edited October 1, 2015 by MirceaKitsune 1 Quote Share this post Link to post Share on other sites
hypov8 1 Report post Posted October 1, 2015 (edited) 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/blendsdo you know what stage types are causing the issue, like alpha blends, gl_one etc.. another area u can changeparseShaderFlagsif (token == "tranZlucent") Edited October 1, 2015 by hypov8 Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 2, 2015 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/blendsdo you know what stage types are causing the issue, like alpha blends, gl_one etc.. another area u can changeparseShaderFlagsif (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. Quote Share this post Link to post Share on other sites
stumpy 240 Report post Posted October 4, 2015 (edited) 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 October 4, 2015 by stumpy Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 4, 2015 (edited) @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: 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 October 4, 2015 by MirceaKitsune Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 5, 2015 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! 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? Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 5, 2015 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 Quote Share this post Link to post Share on other sites
OrbWeaver 508 Report post Posted October 5, 2015 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. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 5, 2015 ... and that's it. The missing attributes in wxGLCanvas were the cause, I added them and now depth buffering works! Cheers again OrbWeaver 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), 2 Quote Share this post Link to post Share on other sites
SteveL 1042 Report post Posted October 5, 2015 Gratz on finding your fix and happy mapping! Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 5, 2015 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 Quote Share this post Link to post Share on other sites
OrbWeaver 508 Report post Posted October 6, 2015 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. 1 Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 6, 2015 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. Quote Share this post Link to post Share on other sites
MirceaKitsune 162 Report post Posted October 9, 2015 Confirming that the latest GIT commit fixes this and works as intended. Cheers Quote Share this post Link to post Share on other sites
