cabalistic
-
Posts
1579 -
Joined
-
Last visited
-
Days Won
47
Posts posted by cabalistic
-
-
Yeah, except as a developer, I don't really have time to do it, because there's always something that needs to be fixed or implemented
So any mission recommendations that you guys can give for VR would be very welcome 
-
1
-
1
-
-
Alpha 4 is available: https://github.com/fholger/thedarkmodvr/releases/tag/v2.0.9_alpha4
It fixes a regression that broke light/shadows and the lightgem visibility in many places, so it's kind of an important update
It also features a few quality-of-life improvements, and a working compass.
-
2
-
-
Thanks, great you're enjoying it!
Meanwhile, I've gotten the compass to work, and I'm currently investigating some rather strange light/shadow problems. Hopefully I can get that one sorted out, as it's currently the nastiest bug I'm aware of...
-
1
-
-
And Alpha 3 is available: https://github.com/fholger/thedarkmodvr/releases/tag/v2.0.9_alpha3
@BuckleBean I've implemented your idea of a cone of mouse movement that does not turn the player view. You can control its size by vr_decoupledMoseYawAngle. Setting it to 0 disables the whole thing
What do you think?
The other noteworthy change is that I've dealt with cutscenes (e.g. the beginning of NHAT): since these take active control of the player camera, I'm rendering them in 2D to the overlay instead of to the eyes to avoid nausea.
In general, I'd appreciate some feedback for this version. I think it is now in a state where I should promote it outside of these forums.
-
1
-
-
Aaaand done, mouse aim indicator is finished
Here's the new release: https://github.com/fholger/thedarkmodvr/releases/tag/v2.0.9_alpha2
-
1
-
-
Still working on the mouse cursor, which I think will make an excellent feature to release a new alpha
In the meantime, if you'd like to play with the fixes and improvements I've already completed, you can find a current dev build here: https://ci.appveyor.com/api/buildjobs/fwf5dhl36dkm2nve/artifacts/TheDarkModVR.7z
This includes fixed text rendering and also a somewhat workable underwater view. Please delete your darkmod_vr.cfg, as I may have changed some defaults that are relevant for performance or correctness!I also started the outlines of a wiki for The Dark Mod VR over at Github. I thought it might be a good idea to document missions and how they perform in VR, as an orientation particularly to newer players that might be interested in the mod. If you'd like to contribute, feel free to edit/create pages for missions and add whatever you find worth mentioning: https://github.com/fholger/thedarkmodvr/wiki
-
1
-
-
Small progress update:
- I found some dormant Doom3 BFG code to calculate light scissors which give a tighter and also more correct bound. That means there should be fewer lighting/shadow glitches, if any.
-
Together with the tighter light scissors, I made a few other improvements that should hopefully provide a minor performance improvement. Nothing game changing, but everything counts
My plans over the weekend are to get a working indicator for the mouse aim and perhaps fix underwater and similar views. I'm also still looking into the mismatched text rendering, but so far haven't found the cause. EIther way, with any luck I'll publish a new alpha over the weekend that should hopefully come a few steps closer to a good seated gaming experience.
-
2
-
Judging from that ingame look: if all else fails, it would at the very least make a cool statue, both in large and small! So even should it not work out as an actual animated entity, give it a marble skin and place it in a large hall, or give it a silver skin and make it a cool lootable object
-
1
-
-
For culling purposes that's fine and already happens sort of like this - but to calculate actual screen space scissors it's simply incorrect, because that involves non-linear projection, and so you cannot correlate scissors of that pseudo-frustum with the actual final frustums.
-
1
-
-
No - both eye have different view matrices and projection matrices, and so their screen spaces have no relation to each other. Worse, the projection isn't even symmetrical, which the engine code computing the scissors assumes it to be. And finally, the backend modifies the view matrices just before rendering, so any scissors the frontend calculated would be invalid at that point, anyway. I have code to recreate valid light scissors, but I cannot recreate portal-clipped scissors at that point - even if the code were correct for the asymmetrical projections, it would touch frontend structures that I cannot access in the backend, and even if I could, it would probably be too expensive.
-
1
-
-
Hm, after looking into it a bit more, I'm afraid I can't fix the stencil-related performance issues
I underestimated how costly stencil operations actually are, and coupled with two views at high resolutions, it's just too much if there are large shadow volumes to be drawn.
The flat game avoids some of these problems by clipping large shadow volumes with their visibility through portals, which can help a lot in notorious scenes. Unfortunately, the way that clipping is done is not valid for the VR views, and I cannot replicate this in any sensible way.
At this point, I will have to look into getting shadow mapping to work in VR and optimizing that.
-
1
-
-
Weird, I definitely set the default values for the bob to 0, but something is overwriting and resetting these values, and I have no idea where or why...
It's not in the engine, I think it must be a script.
22 minutes ago, Bienie said:1. At the start of the mission where you get the prompt "press attack to start the mission" you see a world-spawn only view of the map, where in standard TDM the screen is black all around. I assume this would be the case in standard TDM if it weren't for the black background added on, maybe that can be done here as well?
This is because the blurring out uses a GUI effect, and unfortunately I can't easily distinguish between a GUI "effect" that should be applied to the eye views and actual UI that needs to be redirected to the overlay. So everything GUI-related lands on the overlay right now. This is also why underwater view effect or the bleeding effect appear on the overlay. I need some clever way to redirect those, but it's not high priority right now.
Quote1. The spyglass only creates a flat overlay which doesn't actually zoom.
I'm not surprised. Not even sure how it should work in VR; I don't know if zooming the eye views would actually be pleasant, but other solutions might be too complicated to implement. I'll put it on my list, but I can't promise this will ever get fixed
Quote2. The compass shows up as a big black square when you bring it up in the inventory. I know the compass is notoriously buggy, as even the flatscreen version has had problems with it not showing correctly.
Right, I'll have to check the state of the 2D version right now, and then if it's working there, see if we can get it to work in VR.
Quote3. In-world text is unreadable (fuzzy and "double vision syndrome"). By in-world text I mean the GUI that is on open notes, books etc.
Yeah, this is what I'm looking at right now, but I'm stumped. Haven't found a reason why it behaves the way it does...
Quote4. The text in readables is transparent to the background. It looks pretty dark but when you read something and have light source behind it it's obviously shining through the text and makes it hard to read.
This might not be fixable on my end, as it's likely a material issue - those readables are actually drawing transparent, or at least some of them (some appear fine). But while the main game can basically discard that transparency, I unfortunately can't - or the UI overlay would always appear as a black rectangle blocking your view.
Quote5. I had a bug that suddenly started happening where visportals weren't drawing correctly. It's really hard to explain and it didn't show up in my screenshots unfortunately, but essentially it was cutting out large swaths of things that were mainly around the rim of the portal and just showing skybox there instead. Saving and reloading didn't help but restarting the client did. Not sure if it's reproducible, but if it happens again I'll try to figure out how to explain it more succinctly.
It is theoretically possible that with fast movement you can trigger some things to be culled incorrectly - I might need to increase the frustum size to prevent that from happening. Though if you see it in a still, it might be something else. If you have a reproducible case, let me know.
QuoteThe only thing I can't confirm is the performance increase, but I will have to try different missions in order to confirm or deny. So far it seems to be 120+ fps in low complexity scenes, but hitting low 30's in medium scenes that the flatscreen mode runs just fine. But like I said, I will definitely need more data points (missions played) and will look a bit deeper into the graphical settings (though they looked good at first glance).
Yeah, unfortunately some scenes trigger a massive cost in stencil shadow drawing, and I have no idea why. It's much higher than the doubling compared to the flat version that you'd expect, but it's not consistently this bad. I can't make heads or tails of it, yet, but it's definitely on my list.
-
2
-
-
17 hours ago, nbohr1more said:
Would it be alright if I upload this to our Moddb page?
Or do you plan on creating your own Moddb page for this fork?
I have no objections, but keep in mind this is still a very early version that still has quite a few issues to work out
15 hours ago, stgatilov said:As a minor note, tdm_installer will soon allow publishing user-made versions --- that's what "Custom Manifest URL" is for.
It is not implemented yet, but soon will be.
I'm not sure if it would be easier than simple posting exe + shaders directory though.If you point me to instructions on what I need to do, I'll consider it. Perhaps I can even automate it with AppVeyor
3 hours ago, BuckleBean said:Suggestion 1: If possible, I suggest implementing a "cone of frobbing" wherein for some specified degree of mouse movement, the player's "body" is not turned, but only controls the right hand (for example, the blackjack or when you implement a cross-hair). Then, only once a defined threshold is crossed, the player is turned. This way, for example, one could stand directly in front of a chest and freely use the mouse to select the various items while also having the freedom to look around with your head, but the player's "body" would remain facing the chest. Does that makes sense? The folks at Valve who got HL2 working in VR a few years ago included this option and I think you could cycle through various degrees that corresponded to larger mouse movements (wider angles) necessary to instigate a turn. Sadly, that mod no longer works, so it's hard to show you. This stuff can be hard to put into words.
Yeah, sounds like an idea worth pursuing. I'll have to investigate, though, how this can best be done. I've spent so much time on the renderer, now I'm slowly getting into other parts of the engine (input, in this case) which I'm less familiar with
QuoteSuggestion 2: The HUD feels a little high up, but that could be a matter of taste. Personally, I wouldn't mind needing to physically have to look down for it, but I expect some folks might like it more present/in view.
It should be easy enough to add some cvars to adjust the UI overlay's size and position. Then you could just place it wherever you like. I can probably sneak that into the next version
QuoteSuggestion 3: You might want to consider eliminating head bob altogether. The artificial movement has potential to be nausea inducing, speaking only for myself. I brought this up in the previous thread. My solution involves an autocommands.cfg that I execute with F11 anytime I reload. I'm content to do that if needed. Just something to think about.
I've already disabled bob per default for movement and swimming, since these are controlled by cvars that were easy to adjust. Other than those, I think it's primarily mantling and getting hit that can cause involuntary movement? Unfortunately, those may need engine modifications, so I'll have to look into that.
-
1
-
-
- Popular Post
- Popular Post
Phew, it's almost exactly been 3 years since my first post about my VR modification for TDM. Three more versions of the game have been released in the meantime, and with them come performance improvements that I feel it's finally viable to continue my work on the VR adaptation
So without further ado, head on over to https://github.com/fholger/thedarkmodvr and grab the latest release. It's based on the future 2.09 version, but is fully compatible with a 2.08 install. Although I've tried to make the VR version use its own set of resources (separate `darkmod_vr.cfg` and shader folders), I'd recommend you make a backup or copy of your TDM installation to be able to get back to the flat version cleanly without effort. Please heed the README in the repository, particularly about the choices of VR backends.
Some noteworthy information for this new version:
- performance should be considerably improved from the old alphas. That doesn't mean it's perfect - although the CPU bottleneck is now completely gone, the game is now severely fill-rate limited. So if you have a current-gen headset with high resolution and/or a weaker video card, forget about any supersampling or AA. I also strongly recommend to stick to stencil shadows and disable soft shadows and ambient occlusion - the latter isn't that impressive in VR, anyway, and simply not worth the GPU cost. And even then, there will be some scenes in some missions where reprojection is just unavoidable, even with the beefiest GPU. That being said, I have tried a multitude of maps, and I think it's very playable.
-
the UI is finally usable! Both the menu and ingame HUD elements are projected to a virtual screen in front of your sitting position. It's not the most elegant or immersive solution for the HUD, but it works
- vertical mouse movement is excluded from the VR view - this was suggested by some of you way back, and I think it makes the experience much more enjoyable. It can make it a little hard, though, to aim with the mouse for actions like frobbing items, because there's currently no visual indication to where the mouse is pointing. I'm planning to add one asap, but in the meantime, you can equip a weapon to get a vague sense of your mouse orientation. If you do want to re-enable vertical movement in the view, set 'vr_lockMousePitch' to 0 in the console.
Other than that, I hope you enjoy this new version. Let me know which improvements you'd like me to work on first.
Also, there are probably any number of render and other bugs still left in there somewhere. If you find one, please report them over at the Github tracker (https://github.com/fholger/thedarkmodvr/issues), so I can keep track of them.
Latest Update:
QuoteFYI, I finally got around to updating the VR mod to 2.10. Just follow the installation instructions: https://github.com/fholger/thedarkmodvr/wiki/Installation
There are no new VR features. Development is currently on hold because I'm rather busy working on Half-Life 2 VR. I do want to return to TDM VR as soon as I have the time, though
-
12
-
7
-
17 hours ago, stgatilov said:
Inviting @cabalistic, he changed key mapping on Linux for 2.08
Well, more like "applied a band-aid". ESCAPE key works for me, and unfortunately I don't have any immediate idea to offer if it doesn't for you. You could try to change your keyboard layout to an English variety, if it isn't, maybe that helps?
The whole input handling on Linux needs a major rewrite. It is completely outdated and doesn't work well on modern X systems, I'm afraid. I don't know if and when I'll have time to do that, as it's not a minor task, so if anyone wants to tackle this, please do. Might even be worth considering using something like GLFW or SDL to do window management / input handling to free us from having to deal with X and Wayland on our own...
-
1
-
-
I just tried the installer on Linux, and it has some problems with folder permissions: it created the "fms" folder with permissions 644 instead of the required 755, and consequently it errored out on not being able to create anything inside the fms folder due to missing permissions.
-
1
-
-
I stumbled upon another little problem with the heatHaze shaders. They use some projection math to calculate their effect, and that does not play well in VR - it leads to eye bleed. I'm not familiar enough with how heatHaze works to know if there is a "proper" way to fix it for VR, but for the moment I've replaced the dynamic projection math with a fixed constant. Looks okayish, good enough for now, I hope.
I think I'm getting close to a new alpha version that I'd feel good enough to release
-
3
-
1
-
-
So, I got stereoscopic rendering working. Unfortunately, I'm currently unable to get OpenXR working reliably with SteamVR. It's throwing runtime errors, and generally seems to cause significant CPU overhead. It's entirely possible I'm doing something wrong, but the same code seems to work fine with the Oculus runtime, so this might also be early adopter pain on the SteamVR side. I'll need to dig a little deeper to determine whether I need to open bug reports or not.
Anyway, for the time being I added an OpenVR backend and am trying to keep them in sync. That shouldn't be too hard as long as I'm not diving into input handling.
Issues I'm currently focussing on:
- Light scissors. They are vital for performance, but I need to recalculate them for each eye view, and if done improperly, they can lead to flickering lighting or even mismatched lighting between the eyes. It should be a fairly simple calculation, but oddly enough I still struggle with some border cases. Still, might be good enough for a first alpha.
- Subviews, particularly mirrors, are broken, which is expected, since they need a different approach to adjust them to the eye views. Should hopefully not be too complicated to fix.
Other than that, I think the version I currently have is already a massive improvement over the previous alpha. UI (both menu and ingame elements) render to a virtual screen that is placed slightly in front of you. Not the most immersive solution for the ingame elements, as now the lightgem basically "floats" in the air in front of you, but it was a simple solution that makes everything usable in VR, so a good starting point, I think.
Also, I uncoupled the mouse vertical movement (pitch) from the VR view, which makes it a lot more tolerable to navigate in VR, I think. Downside is that it makes it a little harder to aim and pick up stuff with the mouse, as you don't have any indication where you are pointing at until an item lights up. Will need to figure out a way to render a simple 3D pointer target to indicate mouse aim.
Performance is alright; I'd hoped for more, but current headsets have increased the resolution quite a bit, and TDM is ultimately fill-rate limited. That means there's little (if any) room for AA or supersampling, and you better keep expensive effects like soft shadows or SSAO off - the latter isn't really that important for VR, anyway. I played through "New Job" with my Index set at 120 Hz and could keep that framerate most of the time, but there were a few instances with reprojection. Not too bad, though, but this is with an RTX 2080 Ti, so... There's still one relatively simple optimization that I can do that should save a bit of fillrate.
-
2
-
1
-
Hm, for a conscious design choice I've seen them implemented really badly way too often.
It depends on the particular game, of course. I don't mind checkpoints in many games, but particularly in the stealth genre, they tend to ruin the fun for me. The most striking impact I observed in the Splinter Cell series. Whereas in the first three games, I really enjoyed going for a stealthy approach, I absolutely hated it and felt punished for it in the later games, and the difference is exactly quick saves vs. checkpoints. In the first games, I could quick save whenever I wanted - and it was incredibly fast, both the saving and the loading. And as such, I felt more inspired to try and take some risks, and if I did get caught, I didn't lose much progress and could just try something else.
In the later games, however, getting caught means being reset to the last checkpoint, and if you are taking a stealthy and cautious approach through the level, that means easily replaying your last 5-10 mins. And nothing, absolutely nothing, infuriates me more than replaying the same part of the game over again that I just went through, particularly if my mistake came later. And that led to me very quickly abandoning the stealth approach, because it felt way too punishing. Playing the levels action-style also meant you went much quicker from checkpoint to checkpoint, so less time lost if I die. But playing the games action-style also diminished my enjoyment of the games immensely, and so this is at least one example where my enjoyment greatly suffered from checkpoints...
-
1
-
-
Baby steps: I've got headset tracking working, I think. It looks good in the 2D view, i.e. camera follows headset movement and orientation. Still no stereo rendering, though. That's the next step; in principle it shouldn't be too hard since all elements are now in place. However, I expect a lot of subtle rendering bugs where the contents of the eyes don't quite fit due to some obscure values that haven't properly been recalculated for the eye views
-
2
-
-
I'm pretty sure 2.08 does require more VRAM than 2.07, due to mandatory FBOs and a few other things. I don't know if the increase is enough to make a difference, but peter_spy might have a point.
Also, be sure to enable multi-core enhancements in the options, that should help performance a bit.
-
Bloom in 2.08 is comparatively cheap. You should turn off SSAO, first, or at least set it to its lowest setting
-
1
-
-
Uuhh... okay yeah, that is puzzling. I would suggest replacing the if condition with GLAD_GL_KHR_DEBUG, although if you are sure that CheckRequiredFeatures already finished prior to the call, it really shouldn't make any difference.
Even more confusing: if the extension isn't available, shouldn't that call just crash hard due to a null function pointer, or is GLAD redirecting missing functions to a noop?
-
I'll probably open a new thread once I believe the new version to be ready for alpha testing. But since you're interested, I thought I might give a status update on my progress in the meantime:
- all the backend rendering improvements I wanted to do before returning to VR are now merged to the base game and to be released in 2.09. This makes my life significantly easier in maintaining the VR mod, because I don't have to juggle additional rendering overhauls when merging changes from the base game.
- I have the basic OpenXR setup done and can successfully initialize a VR session with it and acquire all the rendering resources I need.
-
Next up is getting actual rendering to the headset - this won't be a stereo rendering, yet, I just want to get some output so I can verify that what I've done so far actually works
The roadmap / vision for the first new release is roughly to get a decently usable keyboard/mouse sitting experience working. In particular, I hope to have the following improvements over the initial version I released:
- usable UI, i.e. rendered to a virtual screen instead of glued to the eyes
- decouple vertical mouse movement from the view, but possibly introduce an (optional) reticule to indicate the mouse's aim
Let's see how it goes. Can't promise a particular timeline, but I'll try to get something workable asap
-
2
The Dark Mod VR 2.10 alpha is now available :)
in The Dark Mod
Posted
Alpha 5 is out: https://github.com/fholger/thedarkmodvr/releases/tag/v2.0.9_alpha5
A few minor bugfixes, and I finally found time to add a basic comfort vignette, if anyone needs it. The vignette (and other stuff) can be enabled and configured via cvars, which are described here: https://github.com/fholger/thedarkmodvr/wiki/Advanced-settings
I also made the spyglass work in a way by forcing it to render in 2D to the UI overlay. Not the most amazing/immersive solution, but at least this way it functions.