ViveDoom: gzdoom in virtual reality [UPDATE version 0.5.5]

[Xane123]

From what I've seen it looks like it just takes the pick up sprite and turns it into a voxel unless it is a Voxel. Can anyone shed some light on this?

For the shotgun in the video I watched, that looks like what it does, but it'd have to be a custom voxel model to do things like the chainsaw model. I'd like to know how this works myself as I want to eventually purchase a way to possibly play my game in VR but I don't use pickup sprites. I'd like to make my game work with VR for if ViveDoom, GZ3Doom, or that OpenVR thing merges with GZDoom proper.

[PixelWAD]

I think by default it used a standing gun sprite. If that is missing it uses the first hud weapon sprite. So i just replace the sprite with simple voxeldef and i use kvx file for the gun you hold in your hands. Positioning it in the right spot is blind work, but when you position the trigger in the right spot, it feels very good.

I tried it with shadow warrior as well
https://youtu.be/toXEac9BOQw

If you need a sample file, just whistle

[PixelWAD]

I upload it anyway.

I have only one 1 file replacing UZI cause it has a different name than the pickup gun.

RIOT shares the same name, so I had to replace each HUD weapon sprite with voxel individually.
Have a look at pivot/origin of the weapon to get a clue where the hand position is.

[Xane123]

I see; So, all I would have to do is import like a single voxel model then use VOXELDEF to map every first-person sprite for that weapon to the model? Sounds...possibly tedious but I'd do it for my game to look good in VR.

StrangePlacement.jpg

I'd assume the pivot point would be at the trigger directly, but it's 25 units behind the voxel model according to slab6. What part of the touch controller is this pivot point the equivalent of? It seems random where it is placed, above and behind the trigger. Still, this will be easier to test if I get my own Oculus Rift...

In your videos, you use an Oculus Rift, but are you using ViveDoom? Its name makes me think it'd be designed for the HTC Vive. I hope one day this is merged into GZDoom proper.

[PixelWAD]

I have attached 3 screenshots to show you the position of the Touch controller. Maybe it is a bit different with Vive controller?

Also in VR options I had to adjust weapon angle to 45 to feel right. Default is 30 I think.

I'm not sure what I'm using anymore lol.
I think there are 3 versions
1. Old Vive port
2. Newer CV1 port
3. The latest CV1 port + motion controls support

https://github.com/Fishbiter/gz3doom

Even the dev here has a folder with comment "Weapons aligned "well enough"" so I think it's not very obvious how to place them, just trial & error.
Replacing all sprites is pretty fast, it's the aligment that takes time

1.jpg

2.jpg

3.jpg

I also hope that current implementation will make it into main gzDoom fork. Let it remain experimental forever, but I want to play newest mods.
The feature I miss the most is just the mod compatibility and PBR support.

[Xane123]

Ah, I see, so I'll just have to start off with a pivot point similar to your example then tweak it until the controller "holds" it correctly... That'll be hard to test until I get my own virtual reality, which is planned.

It seems this GZDoom version started as GZ3Doom, which mentioned Oculus Rift (and still does on the website), then it became ViveDoom. Seems the developer stopped working on it, so Fishbiter forked it and continued development as OpenVRDoom.

I agree! If a experimental software renderer can be included then why not experimental virtual reality support? I doubt they will do it but I wish they would just add it to GZDoom so it could be up to date. It's unfortunate it seems to be based on a build of GZDoom from June 25th, 2017, as that's over a year of new features that this old build didn't have! My game uses new GZDoom features, so I suppose if I want to make it work with VR, I'll have to just make a short "spin-off" campaign designed to work with ViveDoom. I guess the good thing about that is that I can add more "VR comfort", like slowing down the player, making weapon attacks instant (so the player can pretend to use the weapons), and adding that really common VR "teleport" movement.

[Graf Zahl]

I agree! If a experimental software renderer can be included then why not experimental virtual reality support?

Because an experimental software renderer can just be tested as-is whereas VR support requires a VR headset for testing. None of the active devs either have a headset or much interest in maintaining the feature so it would most likely be broken for longer periods if nobody does any maintenance on it.

[Rachael]

I wish they would just add it to GZDoom

"Just"

It's so easy to say "just". GZDoom should "just" support AT's with CGA cards. GZDoom should "just" add $10,000,000,000 to everyone's bank account.

If those statements sound ridiculous, it's by intent: It illustrates very clearly how easy it is to say something, when you are not the one making it happen.

[PixelWAD]

But is it possible to merge current code with current gzdoom? Even if you don't maintain it, as long as there aren't big changes, it should work. There is already 3d rendering pipeline, vr is stimply added headtracking. Positional tracking might be more difficult, but it has been done.

I think it will be more motivating for someone in the future to fix bugged vr in recent gzdoom, than taking a year old version and trying to get it to work with current code.

DK2 is really old headset and in no way representative about vr. If you haven't tried cv1/vive AND the right software, you haven't experienced vr.

[Graf Zahl]

Let me repeat: We do not have a VR set, and we do not have any interest in getting one. In other words: We cannot maintain this, it will inevitably break because none of us knows the pitfalls. So we choose not to add this code which could develop into a landmine.

[dpJudas]

The code wasn't merged mainly because it was incomplete. Particular the part with how it was linking with the VR SDK was problematic and an acceptable solution was never found. Keep in mind here that a hacky approach to using a library will eventually cause problems for those maintaining it when the hack stops working.

If you want this stuff in mainline GZDoom you need to file a PR of acceptable quality to get it merged in. When I filed my original large PR's Graf spent quite a lot of time before he had analyzed them enough for acceptance. There's a reason for that. Once code is in Graf's repository it becomes his problem if it stops working. As an end user you don't get to feel how much work it actually requires to keep features working.

For example, there are parts of the present shader code that is linked to the VR stuff already in GZD and there's noone around currently that knows exactly why it was needed to deviate from the base shader used for the non-VR version. There might be a good reason or there might not be, but now we're stuck in a situation with a lot of uncertainty of what might break if we merge them.

All the work keeping all those minor features is something I don't think especially Graf and _mental_ gets enough credit for doing. It may not seem like much, but there's so many hours invested in that.

[Gez]

Also the 3D/VR code that's already in there has been a source of minor complications during code refactors. The more code you have, the more likely some of it will cause problems down the line, and that's especially true of interface code. (A function to shoot a fireball can probably be expected to remain largely unchanged for years, because it's in the game sim part of the code which is supposed to remain stable because the game isn't supposed to change; but anything related to input, output, memory management, and other interfacing with the hardware and the OS will have to evolve because these things are not static; and what worked for a Pentium Pro computer running Windows 98 will not work on a computer from the last ten years.)

[Rachael]

And the backend code in question was already refactored, quite extensively, within the last 6 months. So it's not even possible to merge in biospud's code as-is even if we wanted to.

The only person who can fix it is him right now because he's the only one who can develop this stuff.

[hoover1979]

I just ordered an HTC Vive today and will get it in 1-2 weeks. I look forward to trying this out.

[PixelWAD]

I hope the original dev picks it up and update it. Man, Doom in VR is a blast.


Where did you order your Vive that it takes so long to driver?
Btw in about 4 hours starts Oculus Connect 5 where they will present new advances in vr.