VR Expansion Plugin

[mordentral]

Pushed a new commit to the plugin tonight

Early implemented a new method of handling the controller late updates that Epic is 
using in the upcoming 4.18 patch.

It utilizes a double buffer for the scene references in the render thread and effectivly
solves the high velocity tracking issues that were very evident before (when moving fast
the controllers late update would send them flying all over).


also started adding some comments for incoming 4.18 changes to remind myself.

There will be a lot of changes incoming due to OpenXR starting to be supported in engine.

[kusokuso1]

I have some custom hands set up similar to how they are in the VR project, where I reuse the right hand mesh with inverted scale for the left hand.
There's a socket on the mesh of a Grippable Static Mesh Object where X, Y and Z is changed (none are 0). It works good on one hand, but the Y is flipped on the other. I was thinking of multiplying the Y by -1 before the attach but I think the attach/parenting happens in code.

Edit:
I think I found what I should be using.

Set the gameplay tag "HasSeperateSocketsPerHand" (on the grippable static mesh? I assume) and then create 2 different sockets named "VRGripLeft" and "VRGripRight" on the mesh.

Next Edit:
I added the HasSeperateSocketsPerHand game tag to the Grippable Static Mesh Base Class (verified it's still there for the child Actor I'm testing it with), but it seems VRGripLeft, VRGripRight isn't recognized. (tried VRTouchGripLeft/Right, too even though I'm on a Vive, but that didn't work either)

I'm using a VRExP from a week or 2 ago (4.17.1).

[mordentral]

I have some custom hands set up similar to how they are in the VR project, where I reuse the right hand mesh with inverted scale for the left hand.
There's a socket on the mesh of a Grippable Static Mesh Object where X, Y and Z is changed (none are 0). It works good on one hand, but the Y is flipped on the other. I was thinking of multiplying the Y by -1 before the attach but I think the attach/parenting happens in code.

Edit:
I think I found what I should be using.

Set the gameplay tag "HasSeperateSocketsPerHand" (on the grippable static mesh? I assume) and then create 2 different sockets named "VRGripLeft" and "VRGripRight" on the mesh.

Next Edit:
I added the HasSeperateSocketsPerHand game tag to the Grippable Static Mesh Base Class (verified it's still there for the child Actor I'm testing it with), but it seems VRGripLeft, VRGripRight isn't recognized. (tried VRTouchGripLeft/Right, too even though I'm on a Vive, but that didn't work either)

I'm using a VRExP from a week or 2 ago (4.17.1).

I don't actually attach anything and the gripping isn't based off of the hand mesh, it is based off of the controller itself. Unless you actually flipped the scaling on the controller instead of the mesh you aren't running into problems with that.

What you are running in to is that the socket orientation is correct, but only into one palm. You are correct that HasSeperateSocketsPerHand is the way to do it in the template but you used the wrong Socket Names.

VRGripLP
VRGripRP

LeftPrimary / RightPrimary

You can go in to the "GetCorrectPrimarySlotPrefix" function and change those if you wish, it really should be in a variable somewhere instead, but not the largest deal.

[mordentral]

Pushed a new update to the repository today

Added a bunch of functions/nodes to the OpenVR library to control overlay skyboxs and loading systems. They are detailed in the wiki entry below.

https://bitbucket.org/mordentral/vre...unctionLibrary

Corrected an issue that the Epic Motion Controllers have that was evident in my overrides of them, now removing the late update scene view if the motion
controller is deactivated. Otherwise late updates would continue to be used and visually it would appear as if the controller was still active.

[kusokuso1]

I don't actually attach anything and the gripping isn't based off of the hand mesh, it is based off of the controller itself. Unless you actually flipped the scaling on the controller instead of the mesh you aren't running into problems with that.

Sheit, I apologize for wasting your time! You're right, I wasn't flipping the motion controller scale.
You actually told me you're parenting it to the controller itself before, but I forgot...

VRGripLP
VRGripRP

LeftPrimary / RightPrimary

You can go in to the "GetCorrectPrimarySlotPrefix" function and change those if you wish, it really should be in a variable somewhere instead, but not the largest deal.

Awesome thanks a lot. Yep, changing it myself is no problem at all. Thanks.

Jsyk, I actually searched the whole thread for "VRGrip" and didn't get any VRGripRP/LP hits. Checked out Bitbucket VRGrip Interface section too, but didn't see it there.

[mordentral]

Sheit, I apologize for wasting your time! You're right, I wasn't flipping the motion controller scale.
You actually told me you're parenting it to the controller itself before, but I forgot...



Awesome thanks a lot. Yep, changing it myself is no problem at all. Thanks.

Jsyk, I actually searched the whole thread for "VRGrip" and didn't get any VRGripRP/LP hits. Checked out Bitbucket VRGrip Interface section too, but didn't see it there.

Its a template thing, not a plugin thing, I generally don't list template stuff on the wiki for the plugin as they aren't officially part of it.

[kusokuso1]

Its a template thing, not a plugin thing, I generally don't list template stuff on the wiki for the plugin as they aren't officially part of it.

Damnit, sorry. I forgot I was using the (a hacked) template character.
-----------------------------
Having hooked it up, unless I grab the object close to the socket it'll just parent it to the controller with the offset.
Was it always like that? I thought if the mesh has the right-named socket it would always snap to the socket regardless of where the mesh is grabbed.

Edit:
I found that Closest Primary Slot in Range's "Had Slot in Range" was returning false most of the time. Unless the grab sphere was almost perfectly encapsulating the socket it would return false. Looked for a range variable, in hopes of increasing the range, with no luck so instead just removed that check altogether.

Now it's easier to grab stuff and have it snap to the socket, but if I grab an object such that the grabsphere is barely touching it, the mesh'll launch in the direction of the socket without attaching. lol

[mordentral]

Damnit, sorry. I forgot I was using the (a hacked) template character.
-----------------------------
Having hooked it up, unless I grab the object close to the socket it'll just parent it to the controller with the offset.
Was it always like that? I thought if the mesh has the right-named socket it would always snap to the socket regardless of where the mesh is grabbed.

Edit:
I found that Closest Primary Slot in Range's "Had Slot in Range" was returning false most of the time. Unless the grab sphere was almost perfectly encapsulating the socket it would return false. Looked for a range variable, in hopes of increasing the range, with no luck so instead just removed that check altogether.

Now it's easier to grab stuff and have it snap to the socket, but if I grab an object such that the grabsphere is barely touching it, the mesh'll launch in the direction of the socket without attaching. lol

There is a grab range variable, its in local space to the socket so object scale effects it, you can either up the range, or override the HadSocketInRange function in the object itself and always return true and one of the sockets.

You also likely have auto drop distance very low if it is dropping right after being picked up.

Is your object scaled very small from default?

[Luisdcasan]

Hello! First of all I would like to thank you for the plugin.

Im somewhat new to vr and I have two very basic questions:

If I just want the Navigate Movement for my pawn, which section of the blueprints i have to copy?

and the second one:

When I use the VrVehicle wich event would I use to start a Matine for an automatic Ride?

[kusogaki77]

Is your object scaled very small from default?

Cool thanks a lot for the superfast reply and info! I didn't know scale affects it. Awesome!
I'll look around for the grab range and auto drop distance vars. They were all left at default.

The original mesh, unscaled, is a sphere a little bit smaller than the size of a volleyball.
I'm seeing the issue about 20% of the time when it's scaled down to half (xyz .5; size of a wiffle ball),
and 90% of the time when it's scaled to about a quarter of original size (xyz .25ish; size of a golfball).
I'm away from work so can't give exact values.

I could easily just import each of those meshes pre-scaled.

Would you recommend it's best not to muck with scale in UE4, outside of the mesh scale functionality you added to VRGrippables a while back?

[mordentral]

Cool thanks a lot for the superfast reply and info! I didn't know scale affects it. Awesome!
I'll look around for the grab range and auto drop distance vars. They were all left at default.

The original mesh, unscaled, is a sphere a little bit smaller than the size of a volleyball.
I'm seeing the issue about 20% of the time when it's scaled down to half (xyz .5; size of a wiffle ball),
and 90% of the time when it's scaled to about a quarter of original size (xyz .25ish; size of a golfball).

I could easily just import each of those meshes pre-scaled.
I'm away from work so can't give exact values.

its in local space so that if the object is 10x normal size you don't have to grip right as the center to grab there and if it is 0.1 size then it isn't larger than the object itself.

You can just set the range waaaay larger, override the HasSocketInRange function, or pre-scale the object like you said.

It used to be in world space for the radius but it proved better to do it this way for the reasons above.

If you set the radius to the size of the object itself then it should work though.

[Dealman]

Just started playing around with this plugin a bit using your template, looks very promising. I'm having a rather peculiar issue however, I added my own actor - a sword, just a simple grippable one. I can grab it just fine and swing it around - but after a few seconds, maybe 4-5 seconds it just disappears.

Am I missing something?

Also a pretty odd question, but what do you find to be the most convenient method of developing for the VR? I've got the deluxe audio strap, but it's still quite a bother having to take the headset on and off every few minutes. I'm scared resting it on my forehead will mess up the lenses :P

[mordentral]

Just started playing around with this plugin a bit using your template, looks very promising. I'm having a rather peculiar issue however, I added my own actor - a sword, just a simple grippable one. I can grab it just fine and swing it around - but after a few seconds, maybe 4-5 seconds it just disappears.

Am I missing something?

Also a pretty odd question, but what do you find to be the most convenient method of developing for the VR? I've got the deluxe audio strap, but it's still quite a bother having to take the headset on and off every few minutes. I'm scared resting it on my forehead will mess up the lenses :P

I have never seen the first thing...... no idea what is happening there, have you tried debugging it to see what it does?




For the second thing, I tend to dev in 2d, test in VR. Have it set in the template to always be a 2d test pawn unless I launch in vr preview.

[vaanrose]

Hey Mordental,

I just found this plugin while looking for help setting up collision on a VR pawn. Looks amazing. But it appears the template you have up for download is for 4.17 (even though the description says its for 4.16), and I was wondering if you still have the 4.16 version available somewhere? My school's VR lab hasn't updated to 4.17 yet, and I'd love to play around with this.

[Dealman]

I have never seen the first thing...... no idea what is happening there, have you tried debugging it to see what it does?

For the second thing, I tend to dev in 2d, test in VR. Have it set in the template to always be a 2d test pawn unless I launch in vr preview.

Not quite sure either, just tried importing another mesh and it does the exact same thing. 4-5 seconds after gripping it - it disappears. This time I imported a simple weapon mesh and modified the GunBase. Will do some debugging later and see if I can figure out why.

Are there any plans to add support for grippable poseable meshes? I reckon using a poseable would be a convenient way of managing various parts of a rifle(pulling the bolt etc) since you can easily manipulate bones with this component. A bit cleaner than having to use separate meshes.