VR Expansion Plugin

[mordentral]

Added a new game to the list of use cases

Unknightly

[mordentral]

Pushed a new commit to the plugin and example repositories

Template

Added example content for the new VRGestureComponent and GestureDatabase DataAsset.

Plugin

Added new VRGestureComponent - allows you to record and detect gestures, also has some utility functions for drawing and managing them.

Added GestureDatabase DataAsset to store gestures.

I will update the documentation (compile binaries) and go into further details about them tomorrow (it is very late here).

Video going over the final state of them

[mordentral]

4.19 Beta branch is out for template and plugin repositories.

[Mayena]

I have a question about the constraints in the cabinet blueprint. I Replaced the mesh of the cabinet with a car mesh, then replaced the door meshes with car doors. I can now open and close the doors. Now I made this edited cabinet a child of the Sedan blueprint so I could drive it and still have openable doors. The problem now is that the doors don't move with the cabinet but remain in a fixed spot while the cabinet itself moves with the Sedan blueprint. Do you know how I can make the doors move with the Cabinet/Sedan? When I haven't interacted with the doors, they do move with the Sedan nicely, but as soon as I have interacted with them, they won't move with the Sedan.

[mordentral]

I have a question about the constraints in the cabinet blueprint. I Replaced the mesh of the cabinet with a car mesh, then replaced the door meshes with car doors. I can now open and close the doors. Now I made this edited cabinet a child of the Sedan blueprint so I could drive it and still have openable doors. The problem now is that the doors don't move with the cabinet but remain in a fixed spot while the cabinet itself moves with the Sedan blueprint. Do you know how I can make the doors move with the Cabinet/Sedan? When I haven't interacted with the doors, they do move with the Sedan nicely, but as soon as I have interacted with them, they won't move with the Sedan.

Simulating objects unparent themselves when set to simulate, so when you go to drive off later they are left behind.

You have a couple of options.

#1: Stop simulating the door when it is released and attach it back to its parent, ensure that all doors are un-simmed and attached prior to allowing driving.

#2: Use a faked physics door instead that just sets rotation to follow the hand position offset.

#3: Use a lever component for the door, it will actually behave pretty much the same as a door assuming you have the zero point set correctly.


For #2 I intend to make a faked swing door component at some point but it hasn't been high priority due to many examples already being out there for it and larger things to tackle as well as Lever components pretty much being the same thing minus a set pivot point and faked velocity after release.

[Mayena]

Thank you, #3 works perfectly!

[rojo8399]

Has anyone gotten the mechanics for an on-wrist inventory working? Something similar to rec room?
I was doing a ray trace from the HMD to the wrist, and from the wrist to the HMD to make sure they're looking at each other, but I'm almost sure this is a super inefficient/practical way.

[mordentral]

[/B]Has anyone gotten the mechanics for an on-wrist inventory working? Something similar to rec room?
I was doing a ray trace from the HMD to the wrist, and from the wrist to the HMD to make sure they're looking at each other, but I'm almost sure this is a super inefficient/practical way.

If you aren't tracing on tick it isn't that bad, but you shouldn't need to tract to begin with, getting the heads location and forward vector and the component on the wrists up vector and location should let you figure out if they are generally angled towards each other and close.

Can run that check out of tick on a timer or something.

[3DMoss]

Hi mordentral,
Thanks for all the work going into this plugin, it's working really well in my current project. I do have a minor issue with teleport that I didn't have using the Epic template however. When teleporting on uneven terrain, there is a single pop of a frame where the viewpoint shifts up right after teleportation. It's almost unnoticeable, but it is a little distracting. Any idea what could be causing this?

[mordentral]

Hi mordentral,
Thanks for all the work going into this plugin, it's working really well in my current project. I do have a minor issue with teleport that I didn't have using the Epic template however. When teleporting on uneven terrain, there is a single pop of a frame where the viewpoint shifts up right after teleportation. It's almost unnoticeable, but it is a little distracting. Any idea what could be causing this?

Depends, if you aren't projecting to a navmesh then its possible that your trace hit location is underneath a higher point next to it, when the character teleports it will end up shifting upwards to the highest point touching the capsule to remain above the floor. Regardless the default teleport setup traces downwards for the floor after projecting to the navmesh so it shouldn't be any different.

You could also be teleporting incorrectly by not adjusting for the HMD location "GetTeleportLocation" is a helper node that correctly offsets for that.

One last thing is that the VRCharacter has its 0,0,0 location at the players feet, the default character has it at the players center of collision capsule. It felt more natural to have it at the feet for roomscale as all of the offsets line up. This however means that for teleporting you should no longer pass in the capsule half height as an additional offset for the teleport (though that should be an upwards offset not downwards).

I haven't noticed a hitch like that myself though, no.

[Lone_Rebel15515]

I love the plugin, and it has worked wonders for the game I'm working on, but I've run into a slight issue I was hoping somebody could help with.

I am working on a vr weapon system, and currently I'm trying to implement shotgun mechanics, but I'm having some trouble with the secondary grip. For other weapon types, I've simply made the bolt a grippable box with a static mesh child, then scripted whatever interactions I need.

For the shotgun, however, I need the pump to work as the secondary grip point on the gun, as well as have it work as a constrained interactable for the weapon mechanics.

Is it possible to make a child component's grip act as the secondary grip on the weapon, or to make the weapon's secondary grip interactable?

Or am I simply approaching this from the wrong angle?

I'd appreciate any help, as I've been stuck on this for a bit and it's the last thing standing in my way before my system is largely complete.

[mordentral]

I love the plugin, and it has worked wonders for the game I'm working on, but I've run into a slight issue I was hoping somebody could help with.

I am working on a vr weapon system, and currently I'm trying to implement shotgun mechanics, but I'm having some trouble with the secondary grip. For other weapon types, I've simply made the bolt a grippable box with a static mesh child, then scripted whatever interactions I need.

For the shotgun, however, I need the pump to work as the secondary grip point on the gun, as well as have it work as a constrained interactable for the weapon mechanics.

Is it possible to make a child component's grip act as the secondary grip on the weapon, or to make the weapon's secondary grip interactable?

Or am I simply approaching this from the wrong angle?

I'd appreciate any help, as I've been stuck on this for a bit and it's the last thing standing in my way before my system is largely complete.

You can have the pump as an entirely seperate grip on its own to move it, or just track the location of the hand relative to the barrel and handle it yourself.

You don't want to try and re-orient the actor to face the pumps location as that also effects the pumps position since it is a child component.

So if you don't want to do any custom setup, easiest would be to add a another grip to the pump when the secondary grip is started, and remove it when the secondary grip is stopped. However I think you could get cleaner results by doing the pump logic manually off of the secondary grips current location and the sockets location to get barrel offset.

[Lone_Rebel15515]

You can have the pump as an entirely seperate grip on its own to move it, or just track the location of the hand relative to the barrel and handle it yourself.

Okay, this was the route that I was attempting to go, but it turns out I was accidentally referencing the wrong controller, so it wasn't working. Oops.

So I sorted that, but I suck at vectors and math, so I'm having an issue, in that, whether or not it works properly is determined by the direction the weapon is facing. Clearly I'm approaching this incorrectly.

If anyone could tell me what I'm doing wrong here, I'd appreciate the help.

Thanks for the quick response and the help.

[mordentral]

Okay, this was the route that I was attempting to go, but it turns out I was accidentally referencing the wrong controller, so it wasn't working. Oops.

So I sorted that, but I suck at vectors and math, so I'm having an issue, in that, whether or not it works properly is determined by the direction the weapon is facing. Clearly I'm approaching this incorrectly.

If anyone could tell me what I'm doing wrong here, I'd appreciate the help.

Thanks for the quick response and the help.

Inverse transform the position to be local to the gun, you don't want to do this in world space, making it local to the gun gives you only the forward (X....Y for marketplace guns) axis to worry about.

https://docs.unrealengine.com/latest...sformLocation/

[Lone_Rebel15515]

Inverse transform the position to be local to the gun, you don't want to do this in world space, making it local to the gun gives you only the forward (X....Y for marketplace guns) axis to worry about.

https://docs.unrealengine.com/latest...sformLocation/

Awesome, thank you so much. I figured I needed to do it in local space, but had no clue how to get the data to local space.

I have one last plugin related question if you wouldn't mind.

I've got the movement working properly, and I only want it to move on Secondary Used. Which I've also got working. However, when I press secondary use, the the gun sort of rotates away from the secondary hand, then quickly corrects itself.

Is this something you know of / something you know how to fix? It just jumps a bit every time I hit the use button.

Thanks again.

Edit: It seems like it's releasing the secondary grip for a fraction of a second, and the weapon rotation is moving back towards the primary controller's rotation, then snapping back to the secondary controller. I dunno if that helps anything.