VR Expansion Plugin

[MagicBots]

Yeah ok, I exposed the boolean that deals with that yesterday as well as I figured it might be the problem.

The simplecharacter doesn't keep the HMD at a relative position to the actors root, it moves the actors root WITH the hmd and keeps the HMD at X/Y 0,0,0. Due to this there is a boolean in the motion controllers bOffsetByHMD that offsets the tracking frame back by the HMDs position as otherwise they would have that offset you are talking about. (The VRCharacter doesn't do this so it defaults this boolean to false).

Before yesterday this was a private variable to c++ because I was manually setting it on the default components on the simple character. However tracked devices are not default components and will have it defaulted to false.

So with the new version (commit as of 4/12) you should be able to go in to the TrackedDevice and set bOffsetByHMD to true and get your correct transform on the tracked devices, as well as the 7 additional index's.


I realized that people trying things like the simple character and only using my motion controllers would need that boolean exposed anyway, so its a good thing to have regardless.

*Edit* Oh forgot to mention, pretty sure that the SteamVR driver rollback a day ago took away the new Index's of the trackers again. You'll want to be on the SteamVR Beta branch as it is still correct and is what the main will be once they fix the oculus issue.

Thanks it's working now with the Offset by HMD toggle. I noticed they are showing up under "Invalid" with "getValidTrackedDeviceIds" after the driver rollback, but they're still working though your plugin without SteamVR beta branch somehow, and thanks for enabling more trackers.

[mordentral]

Thanks it's working now with the Offset by HMD toggle. I noticed they are showing up under "Invalid" with "getValidTrackedDeviceIds" after the driver rollback, but they're still working though your plugin without SteamVR beta branch somehow, and thanks for enabling more trackers.

Mmm, Invalid is just on epics end, I just assumed that the rollback would have changed their index's back to the old values, but appears not. So should be good to go for awhile.

[mordentral]

---------
Downloaded the VR template zip for this plugin (https://bitbucket.org/mordentral/vrexppluginexample)

Built it and PIE'd. (Just made sure hands were getting tracked and grabbing was working.)

Stopped PIE.

Opened my broken project.

After it finished loading, I tried to PIE on the VREx.plugin template again and found out hands were broke. (Actually, the left hand skeletal mesh from the broken project was taking the place of both hands in the new project, and were locked at 0,0,0). I never copied this skeletal mesh over to the VREx.plugin template. No changes were made to the ex. project whatsoever.

Shutdown the broken project, then the VREx.plugin template project.

Relaunched the VREx.plugin template project

Steam Motion controllers are now taking the place of the hand skeletal meshes and are getting tracked. UI widget is visible on the MCs, but buttons do nothing.

I pm'd you a link to the bad project.
---------

I didn't realize that you were opening two projects at once, that WILL break SteamVR, actually I am surprised that it let you get away with it, used to fully crash out of the editor if something else tried to take over.

I downloaded your project anyway but it doesn't appear to have anything wrong in it, I would suggest never loading up two projects at once with VR plugged in, if you want to migrate then use the migration feature or just don't expect the tracking to work in both projects at once. Even when not running PIE the editor still keeps hands on SteamVR due to being able to hotload into and out of the VR editor, as well as the SteamVR Plugin module loading up references when accessed.

*Edit* Also for future reference, if sharing a project in the future, delete all Intermediate and Binary folders (one for the project and one for each plugin module). This will greatly reduce the size of the upload / download.

[kusogaki77]

I downloaded your project anyway but it doesn't appear to have anything wrong in it, I would suggest never loading up two projects at once with VR plugged in, if you want to migrate then use the migration feature or just don't expect the tracking to work in both projects at once...

Thanks a lot for the info. I actually looked around for threads about running 2 projects (not VR, tho) at the same time, but didn't find anything. I know now it's not.
Whenever I open up that rocket2 project while another, good project is running, the good one gets permanently ruined (whether I save or not before killing everything, and then relaunching the formerly good one solo).

Is there some kind of cache (like in SteamVR) somewhere that's mucking up the motion controllers?

*Edit* Also for future reference, if sharing a project in the future, delete all Intermediate and Binary folders (one for the project and one for each plugin module). This will greatly reduce the size of the upload / download.

You got it. I apologize for that. I'll never do that again unless instructed otherwise.

[pixelvspixel]

I'm trying to do a sanity check and was hoping some other could chime in with experience. I'm trying to figure out what is different between a clean install of the examples project for the VRextension plugin and the vanilla epic VR template in a fresh project. (Switched to the forward render) as far of optimization or performance with lighting.

I've got a really small scene about 16ft x16ft with with only 30-50 at any time in a scene. Nearly everything is a moveable object and I'm not using any static lighting.

- 1 Direction with Shadows (moveable) Lighting Channel 0 (default)
- Skylight pulling from a texture (moveable)
- 1 point light NO SHADOWS on Lighting Channel 1 lighting 2 characters
- 1 point light NO SHADOWS on Lighting Channel 2 lighting some set objects

Everything runs smooth in the default Epic template, but one of those shadowless point lights in the VRextension example scene will induce judder on a Vive.

Anyone have any thoughts. I can't find much talking about dynamic lights in the forward render an what is a good target. I wish I could bake some lights, but I'm moving and turn them off over and over.

Would love anyone one's thoughts on this. I'm going to go take a walk.

[pixelvspixel]

I'm just going to chalk it up to too much overhead in forward rendering. I wouldn't think shadow-less point lights would be such a hit. But I'm just guessing. For the moment, I just dialed back the screen percentage in the Player Controller from 150 to 110 , at least it's buttery smooth again, and that it's my number one goal. I'm working with a 980, so considering it's a target machine experience, I might see if we can work with a Titan or something extravagant.

I'm just happy to have to points in separate channels and a direction (with skylight) running smooth, but it's tough after looking at the sharper res.

[kusokuso1]

Seems once I reach a certain velocity threshold, the motion controllers' position tracking gets more sensitive while airborne. (Using "launch character" on "get player character".) I mean, at higher speeds the slightest change in pos/rot of the actual Vive controller produces an extremely exaggerated/amplified pos/rot of the one rendered in game.

This is the same issue I had experienced before using this plugin, when I had everything (Camera and motion controllers) parented to a box. (Using "add force" on the "box collision".)

[mordentral]

Seems once I reach a certain velocity threshold, the motion controllers' position tracking gets more sensitive while airborne. (Using "launch character" on "get player character".) I mean, at higher speeds the slightest change in pos/rot of the actual Vive controller produces an extremely exaggerated/amplified pos/rot of the one rendered in game.

This is the same issue I had experienced before using this plugin, when I had everything (Camera and motion controllers) parented to a box. (Using "add force" on the "box collision".)

Yeah, its because of the late update transform, it doesn't handle high velocities very well, you can turn off the late update at high velocities to prevent it happening. I started investigating a fix for it last week but still haven't entirely tracked down the root cause yet (or if I can fix it just for the plugin, not all of the scene information is accessible and they opened up a function specifically for late updates that they use).

Epic also switched over to a new method of attaining the transforms for the late update but it has the same problem as well.

*Edit* mmm, even has a ticket for it, been unresolved since 10/16 https://issues.unrealengine.com/issue/UE-37811

I'm just going to chalk it up to too much overhead in forward rendering. I wouldn't think shadow-less point lights would be such a hit. But I'm just guessing. For the moment, I just dialed back the screen percentage in the Player Controller from 150 to 110 , at least it's buttery smooth again, and that it's my number one goal. I'm working with a 980, so considering it's a target machine experience, I might see if we can work with a Titan or something extravagant.

I'm just happy to have to points in separate channels and a direction (with skylight) running smooth, but it's tough after looking at the sharper res.

Forward renderer while mostly functional is also still somewhat unfinished, if you are finding issues with it you should report them in the top thread of this forum subsection to let the developers know so they can look into it.

[Gnometech]

Hey mordentral.

I've been attaching my weapon AActors to UGripMotionControllerComponent in the usual way (GripObject()), with the default GripCollisionType of EGripCollisionType::InteractiveCollisionWithPhysics. The weapon behaves exactly as I want it when it comes to blocking collisions. However, I've noticed that the gripped actor doesn't remain perfectly locked to my hand's skeletal mesh (which is a child of the UGripMotionControllerComponent). I'm assuming this has to do with the full physics simulation going on. Switching over to EGripCollisionType::InteractiveHybridCollisionWithSweep seems to have solved this, which is perfect. I'm very glad you added in this hybrid collision type.

However, in your wiki docs at https://bitbucket.org/mordentral/vre...tionController I see you've marked InteractiveHybridCollisionWithSweep as incomplete. Anything I need to be aware of while using this collision type? So far it seems to be working perfectly, but are there any known cases where it could break? I'll be using these gripped actors in a multiplayer game.

Thanks!

- Dave

[mordentral]

Hey mordentral.

I've been attaching my weapon AActors to UGripMotionControllerComponent in the usual way (GripObject()), with the default GripCollisionType of EGripCollisionType::InteractiveCollisionWithPhysics. The weapon behaves exactly as I want it when it comes to blocking collisions. However, I've noticed that the gripped actor doesn't remain perfectly locked to my hand's skeletal mesh (which is a child of the UGripMotionControllerComponent). I'm assuming this has to do with the full physics simulation going on. Switching over to EGripCollisionType::InteractiveHybridCollisionWithSweep seems to have solved this, which is perfect. I'm very glad you added in this hybrid collision type.

However, in your wiki docs at https://bitbucket.org/mordentral/vre...tionController I see you've marked InteractiveHybridCollisionWithSweep as incomplete. Anything I need to be aware of while using this collision type? So far it seems to be working perfectly, but are there any known cases where it could break? I'll be using these gripped actors in a multiplayer game.

Thanks!

- Dave

Since it is a simulating object that is "constrained" in away to your hand it doesn't get the perfect 1:1 that a non simulating object gets. You can up the constraint strength and lower the damping to reduce this effect but you have to accept the fact that the higher strength the constraint is the less "giving" it is when colliding with surfaces. I changed the gun in the template last month at some point to increase the constraint strength so that it kept to the hand cleaner.


The hybrid grip works perfectly in 99% of cases, that 1% edge case just bothers the hell out of me so I refuse to flag it as finished (it clips through geometry in very narrow circumstances).

[mordentral]

Pushed new commit to template and Plugin, this will likely be the final update before I move the main branch to 4.16 and lock 4.15 down (major changes in 4.16 to a lot of relevant systems). I wanted to make sure that these changes and features got in on 4.15.

Template

Made several changes to correct blueprint compile errors due to new OpenVRExpansionLibrary setup.

Plugin

Final refactor push before 4.16

Added GoogleVR to HMD Types in GetHMDType to keep sync with Epics

Finally was able to convert OpenVRExpansionFunctionLibrary to a blueprint library only now
that it is in its own module. Uses a static OpenVRGenericInterface just like SteamVRHMD.

*WILL REQUIRE BP NODE CHANGES: Due to not being a component anymore all Expansion library nodes will need to be replaced with the same node again
but without the parent calling component.

Added more notes for incoming 4.16 upgrade (Plugin should be good to go day1 of 4.16).

Added SteamVRKeyboardComponent that allows for displaying, interacting with, and getting
data back from the SteamVR Keyboard while in game. Positions itself with the component
wherever it is and polls the events from the keyboard through an overlay it creates to host it.

Is a little finicky due to the keyboard eating controller inputs and displaying the other steam overlay objects.
But is a nice tool at the very least for dev work.

Component has several events that can be Binded to in Blueprint and the OpenVRKeyboard and CloseVRKeyboard
functions.

[MagicBots]

Hi Mordentral.

I'm running into a issue with using SimpleVRCharacter with an IK plugin I'm using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. This is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I'm wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.

[Sleeper.]

How do I update the plugin to the latest version if I already have an older one implemented?

[mordentral]

Hi Mordentral.

I'm running into a issue with using SimpleVRCharacter with an IK plugin I'm using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. This is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I'm wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.

Not without breaking a lot of what epic set up for VR behavior (room scale bounds for one, they will rotate with you then which is incorrect, though I guess they are likely already incorrect for simplechar). Also driving view rotation off of character in a networked environment was not something I felt comfortable doing.

If your IK plugin does not have a variable to expose to drive different elements than I suggest you contact the dev and ask for some, because a closed IK system is not exactly suited to VR (or lots of other uses honestly). Generally any good IK system should allow you to pass in your own Forward vector....which would be the VRForwardVector. Without that, it is incompatible with literally every VR setup currently in use in the engine.

I could maybe add an optional rotate with HMD option, but like I said, I don't like the concept currently.

How do I update the plugin to the latest version if I already have an older one implemented?

Safe Method, should be hassle free, has more steps

1. MAKE A COPY OF YOUR PROJECT (can't stress this enough, if you don't have a backup system you do this regardless of plugin updates, even just engine updates).

2. Replace the current vr plugin folder with the new one (delete old one first)

3. Delete the intermediate folder for your project

4. Right click on the UProject and Generate Project Files

5. Compile

6. Make any required blueprint changes for things that were changed.


Unsafe method, may have to revert to safe method if the engines reference precompiled files are messed up


1. MAKE A COPY OF YOUR PROJECT (can't stress this enough, if you don't have a backup system you do this regardless of plugin updates, even just engine updates).

2. Replace the current vr plugin folder with the new one (delete old one first)

5. Compile

6. Make any required blueprint changes for things that were changed.

[Sleeper.]

Thanks! Will update soon then. Your plugin is amazing btw, saved me a bunch of time setting up basics like movement and multiplayer.