That is not a problem, single player works perfect for me. Glad to hear you are working on it. I’ll keep an eye on the bitbucket.
Component only grip is added, has its own Grip/Drop/Teleportmove functions for now. May refactor in the future so that they are a single function, we’ll see.
Added a early working version of the VRRootComponent to the latest commit. So far appears to be working correctly, description that I post in the OP is below. I tested it with wall collision (not allowing walking through walls) and it actually didn’t feel bad at all, felt like I was pushing the world away from me instead of stuck in place, so no sickness. Granted I have pretty good VR legs at point so I am not a prime test subject for sickness regarding that.
Should slot right in with standard methods of pawn movement though (at least when fully debugged, it is a day old into working correctly).
I guess I can start on the fun stuff again, movement methods is next I think, I would like to get jogging in place working. I also need to do a perf and bug run through of the motion controllers after adding the component grip in and finish fully the hybrid grip system.
VRRootComponent:
A capsule component that when used as a root component will offset its physics collision location and movement sweep logic by the HMDs relative location. Allows you to use standard movement components with VR pawns and have them act as expected (still early and I am debugging it).
Video uses FloatingPawnMovement with MoveTargetComponet with -Z every tick for testing
*Also removed a jitter that was happening when teleporting with pure physics objects held and cleaned up some bugs.
Thanks for awesome plugin!
Is it possible to use it with a PlayerCharacter pawn, that its root CapsuleComponent is following the HMD instead of the VRRoot scene component?
To get it working correctly I had to override some base scene component functions. It still has the same global location but treats it as an offset location when testing movement sweeps or colliding physics bodies. The default capsule won’t work with it because of , I am intentionally breaking the standard behavior of the root component.
That being said I am looking into deriving from the character and replacing the standard capsule with the VR root one instead, i’ll let you know if anything meaningful comes out of it (would be nice for charmovementcomponent to work as it is the most fully featured).
Edit It was stupidly easy and I learned something new today, should have it uploaded later.
Reverted the VRRootComponent back to a capsule component override now that it is working correctly.
@n00854180t I think might be what you were wanting.
Also added VRCharacter (description below), I need to know if any bugs are found with it. The character and its movement system are pretty complicated and include replication, I haven’t tested movement component with the VRRootComponent heavily yet.
VRCharacter:
A character override actor that replaces the default capsule with a VRRootComponent and moves the default skeletal mesh into being the child of a ParentRelativeAttachment component. Also by default adds in two GripMotionControllers set to the correct hands and a ReplicatedVRCamera.
If not wanting to use as a multiplayer character you can uncheck - ReplicateTransform on the camera and Motion Controllers.
I do believe that works how I was thinking - I’ll have to test it. After you mentioned last time that the offset can’t really be more than the size of the playspace (which for some reason I wasn’t thinking of/hadn’t realized) I was going to just go with it and leave issue alone for a while until or if issues popped up, but I do prefer solution.
Awesome work 
It probably doesn’t act how you originally wanted, I keep everything in relative space but I move the root capsules collision to match the HMD and alter component movement functions to use the offset location.
I think i’m going to end up having to re-write a few of the CharacterMovementComponents functions to support the offset fully as well (water detection for one uses a manual trace with the wrong location).
I swear there is an easier way to do it than I am currently, but I bashed my head against a wall for two days and method is working so far so i’ll use it until I figure out a better way (if there is one).
Whewps, forgot to parent the camera to the character in the VRCharacter, will commit a fix in a little bit.
I think the only way to do it “cleanly” would be to change where it handles the late update and moving the components to recompute the new actor transform relative to the VR camera. But that’s messy in its own way and as far as I know there’s no way to split that code into a plugin.
Another option would be to override GetActorLocation/Transform in order to always return the world location or transform of the camera component.
Neither of those would work that cleanly, the late update wouldn’t work at all since it wouldn’t support game logic on the new position and returning the camera location is still working off of an offset that you would have to store and override a bunch of functions anyway, it would also be harder to decouple its location from the actor and the root component also has to return a different location as the movement code uses the roots location, not the actors.
I should be able to get method pretty stable after I re-write some of the charactermovementcomponent though so I am not all that worried. The movement component can’t really work as is anyway as it has alot of code based around standard pawns that you don’t want for VR (physics objects moving you is a nono and all of the step up on code is sickness inducing).
Uploaded fixed version with the camera parented, i’ll start working on a new movement component based off of the character one tomorrow. As is I tested it and works “ok” with the default movement component, just needs tweaks.
Meh, 90% of the character movement code needs to be dropped for VR after looking through the entire thing. Crouching is set up badly for it, step up is bad for it, all capsule code is offset upwards by half of a capsuleheight, root motion is not required…ect ect
I am just going to use a pawn as the base instead of a character and make a basic movement component for it instead of using character movement component. I don’t think re-using the built in character is even remotely worth the effort considering how much of it is useless for case.
being the case, subclassing a character for VR isn’t needed anymore, you can just replace the root component on a standard pawn with the VR Root Component instead. So I am removing VRCharacter again.
Oh well, is why it is a WIP plugin 
If a camera component with Lock to HMD set to true is the root component, that will effectively be the same as moving the actor in the late update. I was considering doing that, but didn’t want to lose some of the CharacterMovementComponent conveniences. If you end up making a custom movement component, that would be the best of both worlds.
Not really, the late update just shifts the render transform prior to actually rendering so it would still be the initial tick position. Also if the camera was the root the controllers would have to be changed to subtract the cameras location from theirs as they work in the same relative space, or they would have to be set to absolute positioning entirely, you would also be missing collision unless you added some sort of unlinked collision to the camera component itself that didn’t follow roll and pitch.
There isn’t a perfect way of doing it right now I don’t think. Going with a barebones custom movement component and the root component that offsets its collision seems to be working well enough to get to where I want to go, I’ll let it ride for now. It won’t (at least in the short term) have some of the more complicated CharacterMovementComponent features, but it also will be better than running traces every tick from the headset since it has an actual collision capsule to work from.
Ok, so I had second thoughts and spent a good deal of time breaking down the standard character movement component, final decision was that it was viable after all. is in its own branch for now due to having to finish up loose ends but I think I got pretty much the entire **** package done today. Includes all of the replication and network interpolation for the base actor movement that the standard character movement component has (I didn’t have to change a **** thing there), and it controls a custom Character Pawn that uses my VR root component so that collision is in the correct location.
I have been working through it and removing areas where it is trying to step up on physics objects (I got pretty sick the first time I ran into that “feature”) and making sure it is using the root capsule offset location for all collision tests.
I need to get rid of a few small quirks still but in general I think it is where I wanted to be. Once I get the movement component rock solid (have to check all movement modes for bugs) I am going to try out a few different movement styles as standard features.
That looks awesome, !
First commit with the completed VRCharacter is up, it is usable, will require more debugging though.
It has specific VRForward/Up/Right vectors for adding movement input based off of the collision capsule if you want look based movement.
Currently it blocks being able to walk through static geometry when moving in the real world, I will add the option to allow clipping through walls if only physically walking in the real world later on.
Walking and falling are the only totally tested movement modes at the moment, let me know if swimming / flying has any issues you run into if you use them.
I’ll post the wiki updates tomorrow
Wiki updates are up, will start adding some pictures to help clear up some areas regarding the VRCharacter.
For the new controller plugin do I add “VRExpansionPlugin” to file - \Engine\Source\Runtime\Projects\Projects.Build.cs?
When I do I can’t build the project.
PublicDependencyModuleNames.AddRange(
new string]
{
“Core”,
“Json”,
“VRExpansionPlugin”,
}
No, in your project folder “/source/projectname.build.cs” add it in there. Plugins are loaded per project not in the engine itself.