VR Expansion Plugin


I m have been trying to get the example template to work for the past 2 days with no lucks, I followed the instruction to switch the engine version (success with no error) but no project file was generated, then I click on the generate project, still success with no error but no project file gets generated.

Is there a pre-build version of example template for 4.18 I can find?


Realized the issue is that i have both VS 2015 and 2017 in my pc, and C++ only lives in 2017, fixed my issue after uninstall VS 2015

Anybody else experience crashing with 4.19 version template here…/?tab=branches ? When playing template it suddenly might crash or when you quickly tap the trigger, the crash might occur. It this known problem?

Its 4.19, in editor in VR there is a crash that results in an infinite garbage collection loop.

It happens in the default template as well.

Aah thanks man. So nothing can do but to wait. Or is there any known “hack” to bypass the crash besides somehow disabling the garbage collection temporally?

Alternatively, is there a way to convert the newest progress of the plugin to Unreal Engine v4.16, that seems to be the best working version of the Unreal so far? I tried to change the Unreal Engine version to 4.16, but it cannot compile the Plugins anymore. I saw, that v4.16 branch is many months behind the current branches so it might missing some stuff.

Thanks a lot for the plugin.

Hi Fellow VR Devs! Just wanted to share a bit of gameplay from what I’ve been building with the plugin. Thanks so much again Mordentral this is an amazing experience to be able to put together VR games!

Check the GameMode in World Settings, i have some similar problem creating a 2d menu lobby for a multiplayer game and when the game launch one hand was missing so in my case was the game mode it works super good if you use the SteamVR_GM in the map level

Needs to be bug fixed on the engines end afaik, others have been running into it without the plugin as well, since 4.19 is a preview build its not the largest deal unless it releases with it still broken.

There is far too much incompatible across 4.18 and 4.16, Epic changed a lot of the back end. You could start with the 4.16 build and cherry pick features from the commits to add to it, but I don’t specifically support all features backwards. A lot of the additions require/d deep character modifications to do and so they would have to be re-written for older engine versions.

If it is something like the interactibles or the gesture component, those should just slot right in without a problem.

Although, while 4.16 was the most stable, I still consider 4.18 the “best VR patch” so far.

“sucked into” sounds like tracking loss more than anything else, more so if they don’t track at first anyway.

Regardless as Kaiser said I have the gamemode set to use the player controller that spawns the correct character, make sure you have either that, or use your own gamemode and spawn the correct character.

Hey, man! Absolutely love your work here, this plugin is a godsend, it solves so many of our issues.

I was wondering though, because there’s one issue we still have. Our game is multiplayer, and we have a mechanic where the players can throw items at each other. Using the Client Authritative movement replication setting, we are able to replicate the gripped movement very smoothly and have the clients be able to pick up items as well. With most other replication settings, it seems the client either doesn’t replicate its gripping or isn’t allowed to grip the actor. The issue however, is that only the host player preserves the momentum of their throw, whereas clients lose all momentum and the item just falls straight down out of their hands regardless of how hard they try throwing it.

Do you have any idea how we can fix this? With most other replication settings, it seems the client either doesn’t replicate or isn’t allowed to grip the actor.

You were missing the log messages from the other attempts, Client authoritative is the only grip type that can be called on the client (it auto replicates the grip upwards so the client has no noticable delay). All of the other types have to be called on the server. I don’t auto RPC those for people because they may want to pass verification data along with the grip request.

You can see the template structure if that is confusing for you, it checks if it is an authoritative grip or not and RPCs it or not.

Generally for things like throwing objects back and forth I would suggest that you use the ClientSideMovement replication mode, while you will have a slight delay while the server inits the grip, it will sync better overall, client authoritive is generally to be used for things like guns and objects specifically for the owning character.

Edit Loss of momentum on the client authoritative isn’t intended though, that may be an actual bug, i’ll look into it.

Edit2 While it shouldn’t have been causing no momentum, the client authoritive wasn’t passing the momentum from the client up, which is needed for a throw to feel correct. A fix for that will be in a patch today later.

Thanks a lot for the great, in-depth reply!

I hope I’m not being too pushy, but I’ve done some more testing and I still can’t quite manage to fix the issue. I tried replicating the Grip Actor / Drop Actor calls and have them use the Force Client Side Movement option. This does indeed seem to make clients able to pickup and drop actors just like the host, albeit with a slight delay and much better syncing afterwards as you mentioned. However, when the client tries to throw the actor it still just drops straight down, whereas the hosts attempts all end up soaring away as you’d expect.

I’m thinking maybe the “Simulate” option for the drop function call might not work as intended for clients in a listen server. Back when we were trying to make our own networked VR gripping system we manually set the items physics to not simulate on grip, and then simulate again on drop. This worked just fine for the host, but just like now it made the clients items simply drop straight down from their hands. It seems to me that maybe the momentum or velocity calculated by the physics engine are simply lost on the client side. I used to suspect this was some weird property we’d accidentally set somewhere, but in my tests now I made a blank VRGrippableStaticMeshActor in which I only set its mesh, had it simulate physics and generate overlap events, so I’m no longer so sure if it’s caused by something we’re doing wrong on our end.

If it’s the case that momentum/velocity is simply lost or never calculated properly on client side, I’m thinking maybe our only option would be to start calculating each hands velocity on tick and passing these values along to the option velocity paramters instead of using the simulate option. Having it be properly simulated by the physics engine would of course be preferable, but as it stands now it seems that just won’t happen properly on our client side for some reason. Which is odd, as I’ve seen it working fine in other projects.

I also tried updating to the newest version of the plugin (We are using the latest 4.19 preview), but in this case the plugin wouldn’t compile. It claimed the “FScopedMeshBoneUpdateOverride” at line 1330 in the VRSimpleCharacterMovementComponent.cpp file was an undeclared identifier.

Finally, wasn’t able to find the part in the exampletemplate where it’s checking for authoritative grips, so my solution was to just RPC all grips and drops as server functions as calling these on the host should have the same effect as calling them on a client. And I’m not quite sure what you meant by this:

Its all working correctly for me (aside from needing to change some brackets in the latest patch to cover when not sending the velocities for client auth).

Are you using the optional angular / linear velocity inputs to the drop node? If you have the inputs reversed it would cause it to appear to drop straight down. But other than that it should be working fine, the plugin already sets simulating automatically and no, clients get velocity applied.

The velocity of attached objects aren’t calculated, but i’m not attaching these objects to the hands and even if I was I am reading their physics body velocity not their component one when I pass in the optional velocities and those update anyway.

The point of the optional inputs is so that clients get the velocity of their release applied to the throw instead of relying on the server to be “close enough”.

Also thanks for the heads up on the scoped call, I hadn’t built a non unity build in a bit so it was skipping over that, I updated 4.19 to fix it and ran a full non unity build to confirm (I generally run those near the end of a version update as I am usually the only one on the previews).

Here, these are screenshots of how it’s currently set up. This is just temporary code I quickly set up for testing, so it’s not anything fancy.

I’m currently messing around with this expansion to use as part of a hobby game i’m designing for VR. I’m very new to this all but so far have found the plugin to be great.

My current issue is that i’m trying to implement a holster system and i can’t quite get my head around why it isn’t working. The just of what i’ve done is on the event of a griprelease of the gunbase it checks to see if the gripped object component is overlapping the holster collision, if it is then attach the gripped object (the gunbase) to the LeftHolster socket attached to the LeftHoster mesh.

I apologise if i’m coming at this from the completely wrong way but, like i said, i’m very new to this.

If anyone can point out where i’m going wrong i would great appreciate it (or even share some tips on a better way of doing it)

Hi all, someone can tell me where download the 4.18 version? i can’t find it on the branches tab (
thank you

What’s the best way to get the hand and the trigger pull amount while holding a gun?
Such as…when you pull the trigger on the controller I want to move the trigger on the gun.

Master is the 4.18 version, master will always be the newest current release.

thank you very much for this fantastic plugin! I try to add body tracking following Marco Ghislanzoni’s tutorial
in I’m finding some problems to put both together. It would be of great help some advice to be able to anchor the camera to the bone of the skeleton as it does in the tutorial.

His tutorial is for non roomscale characters, not all of it will apply, attach your mesh to a parent relative component with the bSetToFoot set to true to root it to the camera.

Hey, I am struggling with HMD Camera access and render to texture support.

Is AcquireVRCamera the right way to do it? C
CreateCameraTexture2D gives me an empty texture.
GetVRCameraFrame fails when I plug an empty var to Target Render Target, and crashes unreal if I plug in an existing texture.

I’ve made sure my hmd front camera works properly outside of my project.

Any hints would be appreciated :slight_smile: