the touch controllers aren't supported, but it looks like it's on the to-do list. Just FYI, this is still pretty early in development and I'd say that it's not quite as far along as the oculus release of GZ3Doom (at least playability-wise). That being said, I'm sure they wouldn't mind another tester, and it didn't look like there are any other CV1 owners volunteering here. You can see above the dev offered to build a current version for me, they may still make a build so you can try it out. I could upload the build I made, but I don't know if biospud wants a release going out yet.RABID wrote:hey, just wanted to volunteer for testing. i have An Oculus CV1 with touch controllers and and have played about 200 hours of Doom and Doom mods in VR.
[GZDoom] OpenVR virtual reality mode
Moderator: GZDoom Developers
-
- Posts: 21
- Joined: Thu Jun 15, 2017 6:20 pm
Re: [GZDoom] OpenVR virtual reality mode
-
- Posts: 1
- Joined: Sun Jun 18, 2017 6:39 pm
Re: [GZDoom] OpenVR virtual reality mode
If you guys need more testers for the HTC Vive, I'd be more then welcome to bug test! I don't get motion sick, so should be fairly easy for me to jump in and jump out. Lemmi know if you have any builds you want me to test!
-
- Posts: 21
- Joined: Thu Jun 15, 2017 6:20 pm
Re: [GZDoom] OpenVR virtual reality mode
Biospud. First off, I feel like I'm not really sure if anything I find here would actually help
________________________________________________________________________________________________________________
Here's a discussion on fixing camera chase: viewtopic.php?f=60&t=55738
Nash here even proposes something that I think may be the solution to the problem. It's pointed out that in 3rd person the weapon originates from the doom guy, and not the camera so the weapons don't hit where the crosshair is. Nash mentions that the crosshair should be an extension of where the weapon is firing, rather than the center of the screen (Nash then says the location of such code is "status bar source code". I believe the motion controller crosshair would have to be independent of the status bar one.
I'm guessing you could attach the VR HMD to a 3rd person camera and make the player be the motion controller (blanking the player model) pretty easily. We would then need a crosshair that is a projection from the direction of the player, not just painted on the statusbar hud.
__________________________________________________________________________________________________________________
If the HMD is attached to an external chase cam it'll have clipping problems/enemy fire/pickups/hitting buttons/etc will be in the wrong place.
If the HMD is attached to the player camera, a way to decouple the weapon origin and firing direction from the camera will need to be found.
crosshair will have to be solved either way unless 3D models (which I'm assuming now won't be distributional within the main) can be used to accurately aim down the sights.
___________________________________________________________________________________________________________________
EDIT: I found Player.AttackZOffset which modifies the origin of where the weapon fires. From googling I can't tell if there's an AttackXOffset or AttackYOffset
I also found something in the source in gzdoom/src/p_actionfunctions.cpp:
https://github.com/coelckers/gzdoom/blo ... .cpp#L3982
The comment line mentions hitscan origin and is also where the AttackZOffset is defined. I think you would have to get permission to do edits here, but the solution may be this; adding the ability to determine the attack offset in 3d space as dictated by the input from an openvr motion controller. I think the weapon will still fire directly towards the center for the screen, but at least you could edit the hitscan origin.
________________________________________________________________________________________________________________
Here's a discussion on fixing camera chase: viewtopic.php?f=60&t=55738
Nash here even proposes something that I think may be the solution to the problem. It's pointed out that in 3rd person the weapon originates from the doom guy, and not the camera so the weapons don't hit where the crosshair is. Nash mentions that the crosshair should be an extension of where the weapon is firing, rather than the center of the screen (Nash then says the location of such code is "status bar source code". I believe the motion controller crosshair would have to be independent of the status bar one.
I'm guessing you could attach the VR HMD to a 3rd person camera and make the player be the motion controller (blanking the player model) pretty easily. We would then need a crosshair that is a projection from the direction of the player, not just painted on the statusbar hud.
__________________________________________________________________________________________________________________
If the HMD is attached to an external chase cam it'll have clipping problems/enemy fire/pickups/hitting buttons/etc will be in the wrong place.
If the HMD is attached to the player camera, a way to decouple the weapon origin and firing direction from the camera will need to be found.
crosshair will have to be solved either way unless 3D models (which I'm assuming now won't be distributional within the main) can be used to accurately aim down the sights.
___________________________________________________________________________________________________________________
EDIT: I found Player.AttackZOffset which modifies the origin of where the weapon fires. From googling I can't tell if there's an AttackXOffset or AttackYOffset
I also found something in the source in gzdoom/src/p_actionfunctions.cpp:
https://github.com/coelckers/gzdoom/blo ... .cpp#L3982
The comment line mentions hitscan origin and is also where the AttackZOffset is defined. I think you would have to get permission to do edits here, but the solution may be this; adding the ability to determine the attack offset in 3d space as dictated by the input from an openvr motion controller. I think the weapon will still fire directly towards the center for the screen, but at least you could edit the hitscan origin.
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
For those interested in testing a bare bones implementation of OpenVR virtual reality mode, I created an installer at https://github.com/cmbruns/gz3doom/rele ... edoom0.1.0.
I think there are still many other things to nail down before attacking the problem of controller aiming. Formic.Sapien's comments are insightful and mostly match my thinking about how to implement controller aiming.
I sketched out a roadmap for future development at https://github.com/cmbruns/gz3doom/issu ... l%3AOpenVR
Please report bugs and request/discuss features over there.
I think there are still many other things to nail down before attacking the problem of controller aiming. Formic.Sapien's comments are insightful and mostly match my thinking about how to implement controller aiming.
I sketched out a roadmap for future development at https://github.com/cmbruns/gz3doom/issu ... l%3AOpenVR
Please report bugs and request/discuss features over there.
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
For those interested in testing, I just posted a new build at https://github.com/cmbruns/gz3doom/releases
This release ("ViveDoom 0.5") features a usable crosshair, improved blend effects, and some automatic settngs for VR.
There is still no aim-with-controller feature. But maybe soon.
Please try it out and give me your feedback. Including error messages, please.
This release ("ViveDoom 0.5") features a usable crosshair, improved blend effects, and some automatic settngs for VR.
There is still no aim-with-controller feature. But maybe soon.
Please try it out and give me your feedback. Including error messages, please.
-
- Posts: 4
- Joined: Sat Jun 24, 2017 1:38 am
Re: [GZDoom] OpenVR virtual reality mode
Longtime Doom fan, this project's finally lured me into posting. Count me in for another Vive tester Biospud.
Logged an hour with 0.5 in E1 tonight. No crashes, no serious visual anomalies. Worst I saw was a few instances of a few pixels of white shimmer at the left and right edges of my vision for a split second, and I could only get that to happen if I quickly turned my head while circle strafing at a full run. Interestingly it was *only* if I turned my head in addition to using the mouse and keyboard.
Had one instance where a pinky flickered briefly between left and right eye when it was practically standing on top of me. Otherwise that was it. Animations were fine, smoke, lighting, decals, etc all looked good. No audio problems either -- music and sound FX played properly, and their position tracked correctly. No framerate issues, had a consistent, smooth 90FPS. Image was sharp and clear with accurate color.
I noticed ViveDoom allows the HMD to freely look up and down, but locks the mouse to the horizontal axis only when VR mode's engaged. Could we get an option to disable that restriction and let the mouse handle X and Y axis viewing freely if that's our current mouselook setting? The only discomfort I experienced while playing was when I reflexively tried to flick the mouse to look up and down -- I played with using mouselook for controlling horizontal movement and was perfectly at ease. I've played about 3-400 hours of games converted to VR via VorpX with conventional KBM input, including full mouselook and find playing that way quite comfortable. About the only thing that'll make me simsick, aside from a certain flavor of framedrop, is when my intentions behind a given control input don't match up with what happens in game.
Setting notes -- I completely switched off headbob, and made no changes to movement speed. I have a preference for Wolf3D style movement and found it to be more comfortable in VR vs. the normal slippery movement, so I paired up ViveDoom with tzkmove to nix the sliding stop to player movement. Worked fine, so ViveDoom is already compatible with at least some mods!
Let me know if there's any other specific feedback or extra info you need, or any specific things you want tested.
Keep up the good work, I look forward to getting to sit down and play some more and to the next build!
Logged an hour with 0.5 in E1 tonight. No crashes, no serious visual anomalies. Worst I saw was a few instances of a few pixels of white shimmer at the left and right edges of my vision for a split second, and I could only get that to happen if I quickly turned my head while circle strafing at a full run. Interestingly it was *only* if I turned my head in addition to using the mouse and keyboard.
Had one instance where a pinky flickered briefly between left and right eye when it was practically standing on top of me. Otherwise that was it. Animations were fine, smoke, lighting, decals, etc all looked good. No audio problems either -- music and sound FX played properly, and their position tracked correctly. No framerate issues, had a consistent, smooth 90FPS. Image was sharp and clear with accurate color.
I noticed ViveDoom allows the HMD to freely look up and down, but locks the mouse to the horizontal axis only when VR mode's engaged. Could we get an option to disable that restriction and let the mouse handle X and Y axis viewing freely if that's our current mouselook setting? The only discomfort I experienced while playing was when I reflexively tried to flick the mouse to look up and down -- I played with using mouselook for controlling horizontal movement and was perfectly at ease. I've played about 3-400 hours of games converted to VR via VorpX with conventional KBM input, including full mouselook and find playing that way quite comfortable. About the only thing that'll make me simsick, aside from a certain flavor of framedrop, is when my intentions behind a given control input don't match up with what happens in game.
Setting notes -- I completely switched off headbob, and made no changes to movement speed. I have a preference for Wolf3D style movement and found it to be more comfortable in VR vs. the normal slippery movement, so I paired up ViveDoom with tzkmove to nix the sliding stop to player movement. Worked fine, so ViveDoom is already compatible with at least some mods!
Let me know if there's any other specific feedback or extra info you need, or any specific things you want tested.
Keep up the good work, I look forward to getting to sit down and play some more and to the next build!
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
Thanks for the detailed report! This is extremely helpful.Red.Queen wrote:Longtime Doom fan, this project's finally lured me into posting. Count me in for another Vive tester Biospud.
Logged an hour with 0.5 in E1 tonight. No crashes, no serious visual anomalies. Worst I saw was a few instances of a few pixels of white shimmer at the left and right edges of my vision for a split second, and I could only get that to happen if I quickly turned my head while circle strafing at a full run. Interestingly it was *only* if I turned my head in addition to using the mouse and keyboard.
Had one instance where a pinky flickered briefly between left and right eye when it was practically standing on top of me. Otherwise that was it. Animations were fine, smoke, lighting, decals, etc all looked good. No audio problems either -- music and sound FX played properly, and their position tracked correctly. No framerate issues, had a consistent, smooth 90FPS. Image was sharp and clear with accurate color.
I noticed ViveDoom allows the HMD to freely look up and down, but locks the mouse to the horizontal axis only when VR mode's engaged. Could we get an option to disable that restriction and let the mouse handle X and Y axis viewing freely if that's our current mouselook setting? The only discomfort I experienced while playing was when I reflexively tried to flick the mouse to look up and down -- I played with using mouselook for controlling horizontal movement and was perfectly at ease. I've played about 3-400 hours of games converted to VR via VorpX with conventional KBM input, including full mouselook and find playing that way quite comfortable. About the only thing that'll make me simsick, aside from a certain flavor of framedrop, is when my intentions behind a given control input don't match up with what happens in game.
Setting notes -- I completely switched off headbob, and made no changes to movement speed. I have a preference for Wolf3D style movement and found it to be more comfortable in VR vs. the normal slippery movement, so I paired up ViveDoom with tzkmove to nix the sliding stop to player movement. Worked fine, so ViveDoom is already compatible with at least some mods!
Let me know if there's any other specific feedback or extra info you need, or any specific things you want tested.
Keep up the good work, I look forward to getting to sit down and play some more and to the next build!
Notes:
* Headbob should already be automatically turned off in ViveDoom 0.5. Did you actually experience bobbing before you adjusted the setting?
* Sorry I'm never going to give you vertical mouselook. You and I have a fundamental irreconcilable philosophical difference on that topic. Sorry.
* I think the white shimmer at the edges might be due to miscalculation of the visible view frustum during culling. I consider this a minor problem that I will look into after we fry some bigger fish.
* Can you tell me a bit more about what you mean by "slippery movement"?
This thread is beginning to turn into a project player feedback thread. I'm going to open a new thread in a more appropriate forum.
I'm leaving this pull request open for now, because incorporating the pull request as-is will help prepare gzdoom for the future improvements we might make to the OpenVR mode. But I am shifting my focus from nursing this pull request, back to player-focused rapid development on another branch. I have some time to work on this right now and I want to use my time efficiently. Thank you so much everyone who reviewed and contributed to this pull request. Your input has been extremely helpful toward getting the build and link infrastructure where it needs to be for eventual incorporation of virtual reality play into gzdoom.
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
I created a new thread for gameplay and testing discussions here: viewtopic.php?f=43&t=57026
-
- Posts: 4
- Joined: Sat Jun 24, 2017 1:38 am
Re: [GZDoom] OpenVR virtual reality mode
Replied over on the new testing feedback thread.
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
My plan is to show the full controller model, with the weapon sprite bolted onto it. I think that would be the most authentic approach.Formic.Sapien wrote: As for the weapons: So are you anticipating creating the weapons yourself? Or would you be interested in existing models (which I'm sure can be resized/tweaked)? If you do want them created from scratch I could at least start working on them.
Here's some of my work submitted to the steam workshop, they're not great, but I made them from scratch myself:
http://steamcommunity.com/sharedfiles/f ... s/?id=2963
http://steamcommunity.com/sharedfiles/f ... d=80954930
http://steamcommunity.com/sharedfiles/f ... s/?id=2672
-
- Posts: 206
- Joined: Mon Oct 14, 2013 2:19 pm
- Location: California, USA
Re: [GZDoom] OpenVR virtual reality mode
I've got the crosshair working OK in my latest release (ViveDoom 0.5). It's not perfect and does not account for the positional offsets you mention. I believe it is possible to get the crosshair perfectly placed, but I don't feel it's a top priority at the moment.Formic.Sapien wrote: crosshair will have to be solved either way unless 3D models (which I'm assuming now won't be distributional within the main) can be used to accurately aim down the sights.
___________________________________________________________________________________________________________________
EDIT: I found Player.AttackZOffset which modifies the origin of where the weapon fires. From googling I can't tell if there's an AttackXOffset or AttackYOffset
I also found something in the source in gzdoom/src/p_actionfunctions.cpp:
https://github.com/coelckers/gzdoom/blo ... .cpp#L3982
The comment line mentions hitscan origin and is also where the AttackZOffset is defined. I think you would have to get permission to do edits here, but the solution may be this; adding the ability to determine the attack offset in 3d space as dictated by the input from an openvr motion controller. I think the weapon will still fire directly towards the center for the screen, but at least you could edit the hitscan origin.
I don't want to fool with AttackZOffset. I feel that would be cheating. It will appear to the player that the weapon is wherever they are actually holding it, but the missiles will actually emit from the standard AttackZOffset.
-
- Posts: 21
- Joined: Thu Jun 15, 2017 6:20 pm
Re: [GZDoom] OpenVR virtual reality mode
Okay, well it sounds like you have a plan of attack here. I don't know if I have enough knowledge-base to actually helpbiospud wrote:I've got the crosshair working OK in my latest release (ViveDoom 0.5). It's not perfect and does not account for the positional offsets you mention. I believe it is possible to get the crosshair perfectly placed, but I don't feel it's a top priority at the moment.Formic.Sapien wrote: crosshair will have to be solved either way unless 3D models (which I'm assuming now won't be distributional within the main) can be used to accurately aim down the sights.
___________________________________________________________________________________________________________________
EDIT: I found Player.AttackZOffset which modifies the origin of where the weapon fires. From googling I can't tell if there's an AttackXOffset or AttackYOffset
I also found something in the source in gzdoom/src/p_actionfunctions.cpp:
https://github.com/coelckers/gzdoom/blo ... .cpp#L3982
The comment line mentions hitscan origin and is also where the AttackZOffset is defined. I think you would have to get permission to do edits here, but the solution may be this; adding the ability to determine the attack offset in 3d space as dictated by the input from an openvr motion controller. I think the weapon will still fire directly towards the center for the screen, but at least you could edit the hitscan origin.
I don't want to fool with AttackZOffset. I feel that would be cheating. It will appear to the player that the weapon is wherever they are actually holding it, but the missiles will actually emit from the standard AttackZOffset.
While in theory it would be cool to have full 3D models of each weapon, I agree with you on this. I'm sure if there's interest it can be modded in in the future, but for now pasting the sprite would make it automatically compatible with all Doom maps/TCs without having to worry about custom/different 3D models.biospud wrote:My plan is to show the full controller model, with the weapon sprite bolted onto it. I think that would be the most authentic approach.Formic.Sapien wrote: As for the weapons: So are you anticipating creating the weapons yourself? Or would you be interested in existing models (which I'm sure can be resized/tweaked)? If you do want them created from scratch I could at least start working on them.
Here's some of my work submitted to the steam workshop, they're not great, but I made them from scratch myself:
http://steamcommunity.com/sharedfiles/f ... s/?id=2963
http://steamcommunity.com/sharedfiles/f ... d=80954930
http://steamcommunity.com/sharedfiles/f ... s/?id=2672
-
- Posts: 4
- Joined: Mon Jun 25, 2018 9:11 pm
Re: [GZDoom] OpenVR virtual reality mode
Hey got a question does the Windows MR headsets work with this?
I have one and would be willing to help test this feature
I have one and would be willing to help test this feature
-
- Posts: 2
- Joined: Mon Jan 16, 2017 2:26 am
Re: [GZDoom] OpenVR virtual reality mode
I can't seem to rebind the vr controllers in options? I can set some stuff but there seems to be hardcoded controls??
Nevermind, I can manually set controls in the gzdoom.ini but a listing of all the vive controller inputs and their mappings would be a little helpful, as it stands gzdoom only reads some of the controller buttons for rebinding some keys and not others.
Nevermind, I can manually set controls in the gzdoom.ini but a listing of all the vive controller inputs and their mappings would be a little helpful, as it stands gzdoom only reads some of the controller buttons for rebinding some keys and not others.