Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openvr Standing/Roomscale #1

Merged
merged 21 commits into from
Nov 7, 2016
Merged

Openvr Standing/Roomscale #1

merged 21 commits into from
Nov 7, 2016

Conversation

Codes4Fun
Copy link
Owner

Changes to allow the player to:

Turn and walk as a means of motion in the game, and prevent penetrating objects (walls, doors, etc) in the game.

Left controller represents body facing direction, it also holds a flashlight, and touch/stick moves in the direction of the controller, the trigger jumps, the touch/stick button turns the flashlight on or off.

Right controller holds the current weapon. The trigger fires the weapon. The touch/stick button reloads the weapon. The touch/stick is an alternative for turning left and right.

Grip/bumper buttons switch between next and previous weapons.

The left menu button, opens the PDA.

The right menu button opens the menu for saving/loading/exiting the game.

A lot of unpolished hacking, so I put it into a branch to be
fixed/completed and cleaned up.

Input should obviously not be in win_input.cpp, need to learn more about
UI input versus game input.

Basically weapons are recentered on tracked controllers. Several weapons
can fire but several need work (chainsaw, grenade, bfg, soul cube).

Hands are still visible, so it kind of looks funny for now.

Movement can be done by walking around (roomscale vr!) and you can bump
into walls rather then penetrate.

Ducking low enough also puts you in crouch mode and allows you to walk
in to vents, and small compartments.

Button mapping may change.
This too jarring in VR. In the future I may re-enable it but reduce the
effect.
The old code depended on seated position to estimate body position, this
doesn't work in standing mode.

The flashlight may be changed to be in the left hand controller.
Attempt at fixing the chainsaw and grenades. Grenades work better but
not by much.

I will attempt another solution for grenades, fists, and the soul cube.
Slight refactor, looking at how variables are used, reduced some
repeated calculations, some further improvements could be made.
I think this is a good solution for the soul cube, fists, and grenades
for now. Some more interesting things could be done for grenades (like
actually using the motion controller to toss them), and fists (actually
using motion controllers to punch), but this is a good interim solution.
The first frame of the BFG fire animation was causing the projectile to
always fire more upward (the animation pitches the weapon to represent
kickback). To fix this I consolidated the muzzle getting code (also used
for laserpointer), and just use the muzzle from the frame before the
animation, that does not yet have the kickback. This really seems like
an animation bug (either in the asset or in the pipeline or maybe in the
animation system), the first frame maybe should not have the kickback in
it already, but in either case the code fix works and maybe is the best
way to do it since it gets rid of the redudant calls of getting the
muzzle position but at the same time creates a depedency risk (the
muzzle should be updated first before using it).
Weird geometry when the controllers are not yet returning data, needed
to set controllers to false.
This is a little hacky. Basically a skin that removes the arms from the
weapons, but wraps other skins (like the invisible skins).

Would be less hacky if I acquired the materials early on during level
loading (it throws an exception if you try to load a material from the
game thread), and would be less hacky if it wasn't done as global but as
a member variable of idWeapon.
This was caused by the new skin wrapping stuff.
It's disturbing in VR. The velocity kickback is okay though.
Swapped jump and reload buttons, it felt more natural to reload with
your gun hand (right hand) and to jump with you navigation hand (left
hand). Might try swapping the jump and flashlight button, if it seems
kind of tough to jump that way on various controllers.

Navigating now moves in the direction of the facing of your left hand
controller.
Basically fixes scaling of the mouse to the screen, which doesn't work
well in windowed mode and VR. Found while learning more about inputs to
do a refactor.
I think this is the more ideal way input should be done in this engine,
through user commands. This also may allow for multiplayer in the
future, but latency will be a huge deal, there could also be latency
issues with doing it this way since the game thread runs 50% faster than
the render thread.

I needed a conceptual direction of the body, so I chose the left
controller, it makes sense since it also controls the bodies locomotion.
This allows players to move in the direction they are facing, both
physically and with the controller.

More tweaks and bug may need to be done.
Something I forgot to include in the last changeset!

Basically the last changeset was to remove some hacks, and this was one
of them!
Minor change to get rid of using global variables.
Flashlight controlled by the left hand!

Swapped jump button and flashlight button. jump is now trigger,
flashlight is now touch/stick button (which feels more like a
flashlight).

Note: at some point need to optimize all the recentering code and static
variables for weapons and the flashlight.
Made things less hacky by moving VR skin code closer to where it likely
belongs.
Not an ideal fix because you lose head position tracking (back to DK1
days).
When moving the left controller it also updates the head position and
viewAngles, but this isn't usually noticed because viewAngles and the
head cancel each other out, but with cinematics viewAngles variable is
not used, so I now have it that viewAngles can be used in cinematics
(you can use the joystick/mouse to rotate the view).
Hopefully the final fix. The same issue with the left controller causing
weird headmovements can occur when the pitch is not zero, so we remove
the pitch before mixing it with the cinematic camera. Also decided to
pull the changes out of the camera function and simply take the camera
functions output and apply against our axis matrix.
@Codes4Fun Codes4Fun merged commit a29cfd2 into openvr Nov 7, 2016
@Seegras Seegras mentioned this pull request Mar 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant