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

I'm working on a VR version - early alpha

Recommended Posts

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?

Share this post


Link to post
Share on other sites

No Honor Among Thieves

I noclipped from the start to the builders' yard and did not see anything.

Can you upload a screenshot?

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.


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

Share this post


Link to post
Share on other sites

Didn't get a chance to fiddle with the driver but I cured most of the artifacts by disabling lightgem split:

 

tdm_lg_split 0

tdm_lg_interleave 1

 

Strangely, this only affects some maps. I was able to set these:

 

tdm_lg_split 1

tdm_lg_interleave 2

 

in Rightful Property without any issue.


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

Share this post


Link to post
Share on other sites

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 work

also 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?


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

Share this post


Link to post
Share on other sites

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)?

  • Like 1

Share this post


Link to post
Share on other sites

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 issues

with rendering and performance so I should live by our defaults.

  • Like 1

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 sight

2) 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 FOV

angles 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 light

4) Convolve, zoom, and crop the FBO to match the correct player view

5) 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 lightgem

shot 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 buffer

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


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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Hmm, if the 360 FOV wrap were vertical rather than horizontal, both the top and bottom LG could be rendered at low resolution

similar to our current scheme. Still gonna burn depth buffer though.


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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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 1

set vr_enable "1"

seta vr_enable 1

seta vr_enable "1"

 

Any thoughts? Does the in-game resolution matter? Tried 2560x1440 & 1920x1080.

Share this post


Link to post
Share on other sites

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" );


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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 GUI

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

 

  • Like 1

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

Share this post


Link to post
Share on other sites

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 by BuckleBean

Share this post


Link to post
Share on other sites

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.

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