VR Expansion Plugin

I’d love to see a Battle Dome style pushback if you walk into static geometry. I always suspected that it would be a good way to handle people putting their heads through stuff, but never got time to test it myself.

It works fine, one of the first VRCharacter commits had exactly that in it and it just feels like you are pushing the world away from you. It was a temp solution though and caused some view floating so I am looking into other ways of handling it for the future and disabled it until I do. The boolean to turn it on/off is still in but isn’t functional until I figure out the best way to handle it.

Thanks for the directions, looks like I had to first do ‘File > New C++ Class’ to get the source folder and then rebuild with the plugin folder.

Decided to do an explanation video…I realized that some of the plugins features aren’t entirely clear.

I’ll offer a precompiled version eventually that won’t require anything but putting it in Engine/Plugins. I just don’t want to start building it for all platforms until I am not updating it multiple times a day.

Great work mordental!

I was led to your plugin via the SteamVR template that Proteus has been working on. He’s done some great work, but I’m not sure I need all that stuff he’s added and I’m keen to understand things myself and so am hoping to build my character up just using your plugin. Some of the things I want to add will be easier for now, with my current level of knowledge, to implement with a Character based starting point that inherits the standard Movement Component vs the Pawn implementation that I think Proteus is using.

I have three questions.

  1. Are you planning to opensource or are you intending to release it commercially when finished? Either way is fine with me, just interested to know the direction.

  2. Do you plan to release a basic template with a full character rig and some example logic (e.g. grip pickup)? I see your demo videos, but I’m guessing the assets and logic in there are from something else you are working on that you are not able to release. Would be a great help if possible, but I understand that you might have your hands full with the plugin itself.

  3. I know your docs mention:

But I think has nothing to do with support in your plugin for any kind of VR based teleporting and you expect that to be implemented separately? If so then I guess the recommended route would be to wait and use the logic that Epic recently included in the 4.13 VR template. Any idea if could be backported from 4.13p1 to 4.12.5? I could try and extract the teleport logic from Proteus’ template but I’m guessing that the Epic version will be more robust for Touch and perhaps even Daydream controllers in the future. What do you think?

  1. Its already open source so I doubt I could keep people from just reimplementing it :p. I intend to keep the repository open and without legal ties.

  2. I may release a demo project with it when I am done with the vrcharactermovement, really though I want most things to just work with standard templates and engine features. The only thing that is outside of standard procedures are the grip functions and having to use specific shortcut nodes for the character movement if you don’t want to do the math yourself.

  3. You can use the VR template from epics teleporting directly and without issues in 4.12.5, also it will still call the characters TeleportTo function to do the teleporting so it will still auto call Post Teleport Move Actors. If you don’t use the VR character than you will have to manually call PostTeleportMove for each controller after the teleport node.

Just tried copying the template folder from 4.13.0 p1 to 4.12.5 and I get an error:

Will try and figure out why. Any pointers would be great.

In my project, I’ve been using a VR character I built ages ago and so my knowledge probably needs a little bit of refresh and update. But if I can get the VR template working in 4.12.5 then I think the default player is derived from Pawn, from my brief look at it when working with 4.13.0 p1. If I need my player to derive from Character, for inherited Movement Component, then my limited knowledge tells me I’ll need to scrap the Pawn they use and build my own VRCharcter derived from the plugin. I’m figuring I can then use the skeletal assets and meshes present in the VR template for my player character. Or is there a way to get the Pawn to inherit the Movement Component? I don’t think there is with UE4 out of the box, unless you derive from DefaultPawn, but I’m wondering if your plugin changes . I’m guessing not.

Hope I’m on the right track with my thinking :slight_smile:

Great to know that it’ll be open source and that you may release a template in the future with best practice examples. Thanks for replying so swiftly!

The movement component is only for the VR character as it assumes several things exist in it. You could add a VRRootComponent to a std pawn and implement a barebones movement system using floating pawn movement as a base though, it just wouldn’t be anywhere as robust as character movement.

The map for the template is 4.13 its not going to directly allow transfer back an engine version, you can copy the blueprint nodes over and they should work.

Thanks!

Ran into a few issues yesterday trying to backport the VR template from 4.13.0p1 to 4.12.5 and so bit the bullet and just went with 4.13.0p1. All working really well.

Thanks for the help and the plugin!

Yeah I made sure it worked on 4.13 the day the preview came out.

Been slow getting the next stable release out, had to go over the entire replication system for the movement component to make it more stable and I am looking at how to modify collision sliding to work better now.

Good news is that 99% of everything is where I wanted it now, just need to get sliding modified.

Also compressed the HMD and motion controller replication structure more so it uses less bandwidth.

New commit is pushed to main, vastly improves the client side experience. Should be good enough for me to quit working on the movement system (replication) now and get back to new features and fixing small issues (making tossing smoother on client side for example).

Expect swimming movement to be slightly broken, I don’t expect people to use it any time soon so I haven’t worked on it yet. Flying movement may have some small issues, but should be generally stable.

Bandwidth is greatly reduced for the replicated camera and controllers, however is heavier on the movement replication to get the additional data I needed to make it more consistent in VR.

_b

Good stuff dude!

Ok so I lied, I added some more to the movement component today to clean it up further…NOW it should be complete.

Merged an update in morning, has some relevant changes. Deciding on the next big part to work on, everything done so far appears to be stable now.


Now forcing late updates on "SweepWithPhysics" grip regardless of if it is colliding or not, since  is not interactive it should have never turned off late updates on collision.

Added OptionalLinearPhysicsVelocity and OptionalAngularPhysicsVelocity inputs to the Drop functions. When passed a value they will override the dropped components velocity after finished dropping.
 is useful for clients trying to throw objects, they can send the release velocities of the body to the server when requesting a drop and the server can apply them to the dropped component on release.
 keeps throwing more natural regardless of latency and simulation differences for the client.

Added GetPhysicsVelocities Blueprint function to GripMotionController, when passed in a ActorGripStruct it will return the current Linear and Angular physics velocities of the gripped RootComponent/Component.
 is a shortcut function, you could manually retrieve it as well through blueprint, these can then be passed from the client to the server in the Drop notification and sent to the DropActor/Component function.

4.13 Preview 2 appears to have finally updated to a newer OpenVR version (preview 1 didn’t have ), I need to make some changes before it will be compatible with it as the Library needs to use the new functions.

Don’t update to 4.13 currently if you intend to use the plugin with it.

Ooops! Wish I read before updating. Locked myself out of my project now. Stupid me :frowning:

Getting “ERROR : UBT error : Failed to produce item:” on recompile.

Anyone know how to easily rollback to P1? Or will I just need to grab the tagged P1 version from Github and build the engine from source?

I’m pushing a working version to a seperate 4.13 branch in a little bit. I still need to re-write the controller model functions for the new Async functions but at least it will work for you besides that.

I did notice some severe performance and slowdown issues with VR in 4.13 P2 by the way that aren’t in 4.12.5 and that I didn’t notice in 4.13 P1, not sure what it is at the moment since it only occurs when looking directly north…

Edit
branch should compile for 4.13, I am auto returning no texture / model for VR devices for now as I need to do a total re-write of that function to be asynchronous

https://bitbucket.org//vrexpansionplugin/branch/4.13%20WIP%20Branch

Great! Will try and compile now against P2.

Thanks for getting working so quickly.