wildmage Posted July 25, 2017 Report Posted July 25, 2017 That's amazing! Would definitively try it ... if I had a VR headset :/ What are you planning to do with the player moves? Keeping them as they are, or adapting them to something like "small teleportations", to prevent illness? Quote Wild Mage Games Wild Mage Games on Twitter
duzenko Posted July 25, 2017 Report Posted July 25, 2017 Then try 2.05 assets That worked. I haven't had time to build my own but I tried both v1 and v1.1 and they both produce some visual artifacts,random black tris around animating objects (etc). Still, better than the whole AI flickering when you get up close.Can't see any visual errors in Chalice of Kings. What map did you try? Quote
nbohr1more Posted July 25, 2017 Report Posted July 25, 2017 That worked. Can't see any visual errors in Chalice of Kings. What map did you try? No Honor Among Thieves Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
duzenko Posted July 25, 2017 Report Posted July 25, 2017 No Honor Among ThievesI noclipped from the start to the builders' yard and did not see anything.Can you upload a screenshot? Quote
nbohr1more Posted July 25, 2017 Report Posted July 25, 2017 Will try tonight. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
cabalistic Posted July 25, 2017 Author Report Posted July 25, 2017 @nbohr1more: Hm, that's a shame. I can't reproduce it either. May I ask what kind of hardware you are running, specifically what kind of graphics card? If we're unlucky, it's one of those issues... Or if you were running in fullscreen, could you try windowed mode? I did have some issues with fullscreen myself, will have to look into that. @wildmage: It's a long road ahead until I could even think about something like teleportation. Even with the added threading, performance might still be doubtful on many missions to actually support roomscale VR, so we'll have to see. Until then, it will be artificial locomotion only. *If* I ever get around to do something like teleportation, the simplest approach probably would be something like dash teleport, where you do small steps into a given direction where the actual movement can be blacked out. 1 Quote
nbohr1more Posted July 25, 2017 Report Posted July 25, 2017 Windows 10 64-bit w\ 8GB DD3 i3-2130 3.4ghz Geforce GTX 1050 I'll try installing WHQL drivers. I'm currently on the Vulkan betas because they fix a known issue with DOOM (2016) but I'll see if the behavior improves with WHQL. I'll also try exiting fullscreen and reducing Lightgem Interleave. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
New Horizon Posted July 25, 2017 Report Posted July 25, 2017 I'm going to create a separate thread to discuss the potential threading changes. Quote
nbohr1more Posted July 26, 2017 Report Posted July 26, 2017 Didn't get a chance to fiddle with the driver but I cured most of the artifacts by disabling lightgem split: tdm_lg_split 0tdm_lg_interleave 1 Strangely, this only affects some maps. I was able to set these: tdm_lg_split 1tdm_lg_interleave 2 in Rightful Property without any issue. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
nbohr1more Posted July 27, 2017 Report Posted July 27, 2017 The same issue is reproducible with the latest WHQL drivers. That said, this build is faster than SVN with com_asyncTic enabled ( Duzenko's attempt at porting some threading from BFG, most of that workalso exists in v2.05 ) even with all Lightgem interleave and split optimizations disabled. Still, this may be where you might consider using an atomic to prevent the VBO \ Cache from processing lightgem data out-of-order from the regular frames so we can keep both optimizations? Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
cabalistic Posted July 27, 2017 Author Report Posted July 27, 2017 Atomics (or locking) won't do any good here, since the lightgem calculation isn't actually part of the threading split. The process currently looks like this: Thread 1 Thread 2 ========================================================= - Lightgem calculation - wait for Thread 1 - other pre-frame work - signal Thread 2 - render previous frame - game tics - wait for Thread 2 - prepare next frame (frontend) - signal Thread 1 So, no parallelism during lightgem calculation, at least not yet. (Thread 2 waits a couple of milliseconds for Thread 1 each frame, so that's definitely something I'd like to improve.) Still, the VertexCache is a potential suspect, but since I can't currently reproduce the problem, I'll have to understand the cause first. What happens if you disable the lightgem rendering entirely (set tdm_lg_weak 1)? 1 Quote
nbohr1more Posted July 27, 2017 Report Posted July 27, 2017 Thanks for the clarification. I'll check lg_weak and tdm_lg_interleave 0 tonight. I'm also wondering if this is somehow fighting with the Threading Optimization in Nvidia drivers. I re-enabled it a few months back since it was working well but our wiki still says to disable it because of historical issueswith rendering and performance so I should live by our defaults. 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
duzenko Posted July 27, 2017 Report Posted July 27, 2017 Are there any gl... calls in front end vertex buffer frame setup?About lightgem: it's quite possible that frontend for lightgem and frontend for player view might conflict with each other, but must be very system-specific because the lightgem stage is relatively short, probably shorter than game tic.Maybe combine lightgem and player view into a single draw command.But I would really like to see the work that's already done in trunk first. Quote
cabalistic Posted July 27, 2017 Author Report Posted July 27, 2017 Except nothing's really changed for lightgem and frontend, they are still executed after one another, just on separate threads. But it's entirely possible that the lightgem stuff influences the vertex cache in such a way that the backend renderer will feel it in the next round... Yes, the frontend still makes gl calls to generate and bind buffers. I briefly considered to go the Doom 3 BFG way, where it uses glMapBuffer to only pass standard pointers to the frontend thread, but that would have been a major rewrite of the vertex cache and everything surrounding it. So instead I created a second (shared) GL context for the frontend thread. Quote
nbohr1more Posted July 27, 2017 Report Posted July 27, 2017 Are there any gl... calls in front end vertex buffer frame setup?About lightgem: it's quite possible that frontend for lightgem and frontend for player view might conflict with each other, but must be very system-specific because the lightgem stage is relatively short, probably shorter than game tic.Maybe combine lightgem and player view into a single draw command.But I would really like to see the work that's already done in trunk first I guess we could draw the Lightgem model to the main renderview if we made the following changes: 1) Move the camera behind the player and hide all objects between the camera and the lightgem line of sight2) Set the camera FOV to 360 degrees so it wraps all the way around to in front of the player (lightgem) but reduce the resolution of the FOVangles above the normal player FOV and cull any rendering from the "above player FOV angles" except the lightgem. 3) Render the lightgem model tris at the lowest sort order (within a scissor\crop) to the PBO for each light4) Convolve, zoom, and crop the FBO to match the correct player view5) Down-sample and convolve the PBO for Lightem value processing Since convolving the 360 wrapped image is probably pretty intense math-wise it may be easier to do one true dedicated lightgemshot from the camera direction facing directly at the player (opposite of the normal camera view). I can't say whether any of that would save on much performance though. In theory you are removing duplicate work but the extra depth bufferdata for the 360 view would probably steal away most of your savings. Though the 2nd "lightgem shot from front" option would mitigate much of that too... Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
BuckleBean Posted July 27, 2017 Report Posted July 27, 2017 Oh, I wish I checked these forums more frequently. This is extremely exciting. I'd love to help out, but sadly, I'm no coder and don't understand much of this discussion. Still, I have a Rift & a Vive and will plan to test both. I'll probably only have time to test one tonight. I'm happy to give any feedback. Please let me know if there's anything specific you'd like me to do or look for. Outside of windowed mode, are there any other settings I ought to pay attention to? Quote
nbohr1more Posted July 27, 2017 Report Posted July 27, 2017 Hmm, if the 360 FOV wrap were vertical rather than horizontal, both the top and bottom LG could be rendered at low resolutionsimilar to our current scheme. Still gonna burn depth buffer though. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
cabalistic Posted July 27, 2017 Author Report Posted July 27, 2017 @BuckleBean: You need to put "set vr_enable 1" in your autoexec.cfg, since VR support is disabled by default in the current build. Other than that, have fun. But watch out, no comfort options or anything, so it probably takes a strong stomach In any case, I'd be most interested in performance and possible visual artifacts you encounter (other than some shadows being inconsistent between the eyes). Quote
BuckleBean Posted July 27, 2017 Report Posted July 27, 2017 @BuckleBean: You need to put "set vr_enable 1" in your autoexec.cfg, since VR support is disabled by default in the current build. Other than that, have fun. But watch out, no comfort options or anything, so it probably takes a strong stomach In any case, I'd be most interested in performance and possible visual artifacts you encounter (other than some shadows being inconsistent between the eyes). Hmm... no luck. Can't get it to launch in VR. Tried both the Rift & The Vive. Tried with SteamVR running & without. I also tried all of these permutations in the autoexec.cfg: "set vr_enable 1"set vr_enable 1set vr_enable "1"seta vr_enable 1seta vr_enable "1" Any thoughts? Does the in-game resolution matter? Tried 2560x1440 & 1920x1080. Quote
nbohr1more Posted July 27, 2017 Report Posted July 27, 2017 Should be: seta vr_enable "1" by our conventions. Try opening the console and typing vr_ then tab to see if the name of cvar differs for some reason? Hmm the cvar code should probably be moved to either the rendersystem class or the game syscvar class. also add CVAR_ARCHIVE idCVar vr_enable( "vr_enable", "0", CVAR_RENDERER | CVAR_BOOL | CVAR_ARCHIVE, "enable OpenVR support" ); Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
BuckleBean Posted July 27, 2017 Report Posted July 27, 2017 Excellent, will do. I'm also downloading a fresh instance of TDM to work with since I've mucked about with a bunch of settings trying to get it to work with vorpx. While I wouldn't expect it to be an issue, this should rule out any random changes I've made. I'll report back when I can. Quote
BuckleBean Posted July 27, 2017 Report Posted July 27, 2017 Great news, I'm in business. I'm off to put the kids to bed. Looking forward to jumping back in as soon as I can. Quote
nbohr1more Posted July 28, 2017 Report Posted July 28, 2017 Atomics (or locking) won't do any good here, since the lightgem calculation isn't actually part of the threading split. The process currently looks like this: Thread 1 Thread 2 ========================================================= - Lightgem calculation - wait for Thread 1 - other pre-frame work - signal Thread 2 - render previous frame - game tics - wait for Thread 2 - prepare next frame (frontend) - signal Thread 1 So, no parallelism during lightgem calculation, at least not yet. (Thread 2 waits a couple of milliseconds for Thread 1 each frame, so that's definitely something I'd like to improve.) Still, the VertexCache is a potential suspect, but since I can't currently reproduce the problem, I'll have to understand the cause first. What happens if you disable the lightgem rendering entirely (set tdm_lg_weak 1)? Findings: Both tdm_lg_weak and tdm_lg_interleave 0 will cause the problem. I had Threaded Optimization set to auto in the driver. Forcing it "On" caused crashes or rendering bugs. Forcing it "Off" cured some things(I was able to enable sync via r_swapInterval 1 without errors and could even exit to the GUI, however uninstalling the mission caused the GUIto go haywire again). Not to blather but did you see this: Fabien Sanglard - The rendering system is now broken down in a frontend/backend: It reminds me of the design of a compiler which usually has a frontend->IR->backend pipeline. What this inspired by the design of LCC which was used for Quake3 bytecode generation ? I wonder what are the advantages over a monolithic renderer like Doom, idTech1 and idTech2. John Carmack - This was explicitly to support dual processor systems. It worked well on my dev system, but it never seemed stable enough in broad use, so we backed off from it. Interestingly, we only just found out last year why it was problematic (the same thing applied to Rage’s r_useSMP option, which we had to disable on the PC) – on windows, OpenGL can only safely draw to a window that was created by the same thread. We created the window on the launch thread, but then did all the rendering on a separate render thread. It would be nice if doing this just failed with a clear error, but instead it works on some systems and randomly fails on others for no apparent reason. The Doom 4 codebase now jumps through hoops to create the game window from the render thread and pump messages on it, but the better solution, which I have implemented in another project under development, is to leave the rendering on the launch thread, and run the game logic in the spawned thread. 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...)
BuckleBean Posted July 28, 2017 Report Posted July 28, 2017 (edited) I've had a chance to play with this for a short while. I'm thoroughly impressed! It's further along than I expected. I've been playing TDM with vorpx for a while now and once this is complete, that method will be obsolete. You've got something very special and I'm looking forward to seeing where this goes. I spent some time in "Crucible of the Omens: Behind Closed Doors" & "A Matter of Hours." Here are my notes. 1. The game would not launch into VR on the Rift, which is surprising since you're using openVr. I'm not sure if you have one or intend to support it anyway, but I'm happy to continue to help test. I was successful with the Vive.2. My monitor is 2560x1440. The game would not launch in VR unless I changed it to 1920x1080. Not really a priority, but something to be aware of. 3. The game consistently crashes when restarting. I noticed this when downloading/installing a new mission, for example. 4. In addition to shadows, you're likely aware that similar issues exist with other effects to do with reflective surfaces and some light sources. 5. Similar to the problem with UI elements, you're likely aware this also applies to readables. 6. I'm using MSI afterburner/RTSS to monitor FPS. I think it was mis-reporting. I was seeing framerates anywhere from the 150's to the 270's, which seems impossible. I also experienced a bit judder in certain locations, which is a sign I was going below 90fps and re-projection was not kicking in. It could be something to do with my setup. I tried adding the following to my autoexec.cfg and removing it, but got the same result: seta com_fixedtic "1" , seta r_displayRefresh "90" , seta tdm_lg_interleave_min "1"7. You may wish to eliminate head bob for comfort reasons. I'd be curious if you could make this happen automatically. As it is now, I bound F11 to "exec autocommands.cfg." In my autocommands.exec file, I have the following: seta pm_bobroll "0" , seta pm_bobpitch "0" , seta pm_bobup "0" Again, this is truly remarkable. It's honestly all I've wanted once I became aware of what was happening in the VR space. I'm happy to continue providing feedback. Anything specific you're looking for, just let me know. Here are my specs: Win 10 - i7 7700k @ 5gHz - GTX 10880ti - 16GB RAM Edited July 28, 2017 by BuckleBean Quote
stgatilov Posted July 28, 2017 Report Posted July 28, 2017 Yes, the frontend still makes gl calls to generate and bind buffers. I briefly considered to go the Doom 3 BFG way, where it uses glMapBuffer to only pass standard pointers to the frontend thread, but that would have been a major rewrite of the vertex cache and everything surrounding it. So instead I created a second (shared) GL context for the frontend thread.I am pretty sure that rewriting vertex cache to BFG style would improve performance a lot. We had discussion about it on dev forum recently.The current way of creating new vertex buffer for each animated mesh each frame (in random order) is just a mess.The way BFG does it (single huge vertex buffer mapped + manual double buffering) seems like one of the proper ways to do vertex streaming in OpenGL. 3. The game consistently crashes when restarting. I noticed this when downloading/installing a new mission, for example. Most likely, it is this bug, already fixed in SVN version. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.