VR Expansion Plugin

[mordentral]

Oh my, this Plugin couldn't have come at a better time. Literally just spent this last weekend testing my Vive game with some friends, and one of the biggest issues was the grabbing system I had made. My solution, using merely the built in blueprint functions was to turn off gravity on grabbed components. This wasn't the ideal solution but it worked for the most part. That said it seems this plugin gives far better control and I hope to implement it.

Could you by chance give some insight into the setup of the "New grip style" video? I've got a line trace on the controller trigger, then checking my grabbed object and then calling grip actor from your plugin, but it seems to go a bit crazy once attached. Will have a further tinker, but this does look promising. Great work!

If it is "going crazy" after pickup and you are using the Interactive Physics Grip then you probably have collision on the controllers themselves enabled and it is overlapping. You'll want to put them on their own channel and set the gripped object to ignore collision with that channel when held. The IPG uses a kinematic body and a joint attached to the gripped object, so it is still fully simulating and will collide with all other physics bodies that aren't set to no-collide with it.

My test project has collision off on the controllers, but I used have it enabled and run them on the same channel as my traces and set held objects to ignore them on grip.

Thank you so much for the HMD type! This makes my life so much easier. However, ParentRelativeAttachmentComponent does not seem to work at all. I looked at the code and it seems like it should but all that's happening is occasionally, there will be an offset of the child component of the ParentRelativeAttachmentComponent. It just sticks at an odd rotation, and keeps following the HMD rot at that offset rotation 1 to 1. I tried with both Static and Skeletal meshes, and tried yaw values between 1-3 as well as much higher, locked on pitch and roll.

Do you have it set to 0,0,0 of the Camera? I use it for the base point of my IK arms and haven't had a problem. Although I did have a commit up for all of 10 minutes with bAbsoluteRotation=1 in the attachment component by accident that I removed so I guess it is remotely possible you downloaded it in that 10 minute span?



*Edit*

Also please ignore the VRRootComponent in the files currently, I am iterating over several methods of having a dynamic root capsule and the first attempt was way too CPU heavy. I branched it to not effect default for now and am going to try re-writing all of the movement, penetration, sweep, and physics body transform update code in a primitive component instead.

[Defaultsound]

Ah thanks for that. At first turned off collision on the controller meshes, but it seemed to still move around. Then changing the grip collision type to "Interactive Collision with Sweep" seemed to fix it, and now it works great. My only question is, would it be possible to add instead of actor to grip, component to grip.

In my game at the moment I've got a lot of blueprints with nested components with physics simulated. Hence I would trace for components rather than actors. Would this be possible?

[mordentral]

Interactive Collision with sweep won't have true physics interaction by the way, it is there for cases when you don't need true physics interactivity with the environment (will still interact with simulating objects) but still want held objects to not pass through walls. If you are just grabbing and moving things like handles then you would be better off using PhysicsOnly as it is faster and locked to the hand. Each grip method has its uses really, the non interactive ones are good for things like swords and items that you don't want pulled from the hand on collision.


How much was the physics interaction grip moving for you though? I have it using late updates right up until collision with an object, then it will stop late updates to have less visual penetration. You can adjust the grip strength and physics damping in the motion controller properties currently, if the stiffness was too high and it was jittering when colliding with something then you can adjust the stiffness and damping to smooth it out. Also if the object being lifted has a lot of mass then you may need more stiffness to lift it without movement.



I intend to add component grip as an alternative to actor grip, it won't be hard to add, literally just don't gather the root component and use the passed in component instead. It would make things like levers and slides and things far easier to interact with as well.

I was planning on adding component grip at the same time that I move the Grip strength and damping out of the controller and into each grip call on a case by case basis.


*Edit*

I will mention that for multiplayer environments I'm not sure of the cleanest way to handle what you are doing. Setting movement replication on/off is Actor wide, not on a per component basis, so to be safe I will be turning off movement replication on the entire actor of a gripped Physics simulating component.

[Defaultsound]

Just tested "Interactive Collision with physics" again now and it seems to be fine. I think what I forgot to do was to turn off the trace once it had hit an object. Right now my blueprint is a bit of a mess, since I'm trying to work from a duplicate, so things got a bit confused. Basically it was moving around a lot. I ended up analysing the VR template and found I had setup the World offset value slightly wrong as well, so I think that didn't help either.

Good to hear about the grab component, for me that would be a greatly appreciated feature

[mordentral]

Just tested "Interactive Collision with physics" again now and it seems to be fine. I think what I forgot to do was to turn off the trace once it had hit an object. Right now my blueprint is a bit of a mess, since I'm trying to work from a duplicate, so things got a bit confused. Basically it was moving around a lot. I ended up analysing the VR template and found I had setup the World offset value slightly wrong as well, so I think that didn't help either.

Good to hear about the grab component, for me that would be a greatly appreciated feature

I'm actually adding it in now, needed a break from the VRRoot dilemma. Keep in mind that I am unsure how well nested simulating components are going to work with multiplayer, for single player it should be fine right off the bat but having them all on the same actor means that turning off movement replication turns it off for all of them.

[Defaultsound]

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.

[mordentral]

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.

[mordentral]

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 this 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.

[JackDanielEC]

Thanks for this 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?

[mordentral]

Thanks for this 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 this, 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.

[mordentral]

Reverted the VRRootComponent back to a capsule component override now that it is working correctly.

[MENTION=11208]n00854180t[/MENTION] I think this 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 this 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.

[n00854180t]

Reverted the VRRootComponent back to a capsule component override now that it is working correctly.

[MENTION=11208]n00854180t[/MENTION] I think this 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 this 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 this issue alone for a while until or if issues popped up, but I do prefer this solution.

Awesome work

[mordentral]

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 this issue alone for a while until or if issues popped up, but I do prefer this 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 this method is working so far so i'll use it until I figure out a better way (if there is one).

[mordentral]

Whewps, forgot to parent the camera to the character in the VRCharacter, will commit a fix in a little bit.

[n00854180t]

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 this method is working so far so i'll use it until I figure out a better way (if there is one).

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.