I just checked, I deny movement mode switching during climbing, so the template doesn’t have a “changed movement mode during climb” check. Just put the pawn into falling or manually set them to the movement mode that you want / end climbing.
Got the camera buffer capturing working, needs some work still to ensure that everything is safe, but works great.
**** looks interesting, can’t wait to test it out. Great work !
Hi, thank you for the reply.
What I wanted to do is something more “natural”. You have an object in your right hand but you want to grab another object with your right hand so you switch hands just grabbing the object you have to your right hand with your left hand. Many vr games do (hope it make sense).
I have another problem. I have not tested a lot but when I’m running vr mode from editor and I select “Run dedicated server” it will launch the game spawning a “normal” actor instead of the vr actor. Why? It’s a problem of mine or it’s common?
Thank you!
…Yeah that is exactly what it does, “dropping” is just telling the hand to release it so that the other hand can pick it up without interference, if you drop/pickup on the same frame then it just switches hands, think of it like in real life where the one hand lets go when the other hand grabs.
If you try the template out every object can be swapped back and forth between hands seamlessly, the only things that don’t are two handed grip objects when you are gripping at a secondary point as it uses two handed interactions then. You just check if the other hand is holding the object when going to pick it up, and if so fire a drop command to that hand, and continue picking the object up.
Also the editor doesn’t support running in VR outside of the VR Preview mode, dedicated server mode may be broken in VR, I haven’t tried it as it generally isn’t fully functional anyway.
Thank you
Hello ,
Thank you for your feedback. Just one more question, when i adjust the parent class of the movement BP to arm swing forsay, i get the controllers stuck on Teleport instead. Can you tell me how to adjust setting in your plugin template? Sorrry for the very noob question, im just a designer by trade.
Cheers, and thank you for your work!
In the template I have enums for the controllers that are set LeftControllerMovementMode / RightControllerMovementMode, when you press the grip buttons it cycles between these Enums, the movement logic changes depending on what the current enum value is for each hand.
When I free grip an object with a manipulation grip I am expecting it to create freely rotational constraint between the touch point of the grab sphere and the touch point of the gripped object.
What appears to happen is that the constraint is made to the location of the Grip Motion Controller instead of the touch point of the grab sphere. Also the orientation of the controller affects the gripped object and sends the object spinning madly.
When I try to counter spinning effect by making the object interactible with Ignore Hand Rotation ticked I get strange behaviour where the gripped object only behaves correctly when gripped at its origin.
Is intentional? I have a large crank wheel I want to turn by free gripping its circumference with the a rotationally free manipulation grip but can’t for the life of me get it working. It’s seems it should be simple. 
I’m a bit confused. Its entirely possible I’m misunderstanding things. I’d appreciate some advice.
Manipulation grips offset is relative to where you grip it from, it makes a kinematic actor that holds the offset from the hand (the sphere location) and connects to the point on the object you are touching, it sounds like you are passing in an incorrect transform or not actually using the manipulation grip?
Also the manipulation grip does keep one axis of rotation, roll, as that allows for turning door handles and the like, but that shouldn’t effect a properly setup wheel.
You may want to turn off late updates on all Manipulation gripped objects, I used to force it off but decided that it was a bad idea to force any behavior like that. Late updates tend to break physics constrained objects like that as it will force them out of their bounds.
Thanks. I’ll go and check and double check the things you point out in my code. The problem with still having one axis of rotation still enabled with the manipulation grip is that a twist of the hand will turn a huge wheel right round, hence my experiments with Is Interactible and Ignore Hand Rotation (everthing else not limited, I’m using a physics constraint for the rotation.) does behave unexpectedly I think.
I’ll do a test in your template level and see if I can screenshot whats going on…
In your template level I set the free default grip type to be manipulation on the PotionMesh component in the PotionActor with no other settings changed. It behaves oddly (to me.) I’d expect it to just dangle there from the grip point (allowing for the hand rotation you mentioned.)
It does for me, what is it doing for you?
For me the gripped potion spins madly and appears to be attached to the motion controller component origin, not the grab sphere.
How strange. The only change from your downloaded template map was the grip type change to manipulation.
I wonder what I’ve messed up?
It’s 3:30am here, which probably doesn’t help me. I’ll experiment more tomorrow and post again. Thanks for your help, these issues are driving me nuts and now you and I seem to get different results on an identical project. What a headache.
Mmmmm, No I was able to reproduce by holding the very tip of the potion bottle, its just fighting the angle it wants to hold with controller roll. Removing the roll drive fixes it and it just swings loosely then.
I’ll remove the roll from the manipulation grip for now, it actually was never going to work as well as interactive components for that anyway consider it takes the controllers initial angle into account as well.
Edit I may have to look into manipulation grips root location for the constraint some, regardless I can’t push any changes live until I clean up some code for the Vive Puck and the Camera nodes tomorrow.
Thank you very much. Your post was my first ‘internet’ when I woke up and it has cheered me up lots! I’m not going mad after all.
EDIT: Also saw lots of BlueprintLog overlap messages when picking up the template gun on what I presume is your new stereo layer widget. Really cool. Made me feel like The Terminator.
Yeah I fixed that last night, someone was complaining about overlaps misfiring and I added a debug log to the gun for testing and forgot to remove it.
I can’t make the HeadMesh component of the pawn cast a shadow. It’s set up the same as the mannequin hands as far as I can see. Could the problem be due to the proximity of the head mesh with the camera?
Cheers
EDIT: I fixed it by replacing the skeletal head mesh box with the GenericHMD static mesh from Epic’s VR template.
Yeah it was just a box, shadow casting was probably turned off for it.
Also I’m not sure I should be removing twist and changing manipulation grips point of contact. The problem is that I will have to start passing in the hit location of grip attempts in order to move the interaction point and most uses of manipulation grip don’t require . It is more overhead for something that is rarely used and I can’t really support every possible interaction with just plugin grips anyway, which is why I added the custom grip in the first place. Also on overlap there IS no clean hit point so the logic on that case is difficult to take care of automatically as it pretty much depends on the how the user wants to interact with the object.
I think your use case would be better served by using a “custom grip” and manually constraining the hand and the object when the “OnGrip” event is fired, then “OnDrop” removing the constraint. will let you get the exact functionality that you want. That or adding a dedicated “handle” interactor to your wheel that you can grip instead that is then constrained to the wheel.
Edit Also your greyed out simulate is caused by the mesh not having a physics collision set up, also I made a “wheel” that is constrained in world to only rotate on the rim axis and it works fine with a stock manipulation grip. I’m not entirely sure what you are trying to accomplish though.
I think I understand the concerns you have about the overhead here but I disagree that the use I want to put the manipulation grip to will be rarely used. My preference is that the naked manipulation grip should act like grabbing an object between your thumb and finger (I get your point about being object/grip specific) and letting it hang free to be moved around without hand rotation playing a role (optional?). I think most people would expect behaviour as it is very useful for all sorts of situations.
Would you removing the hand twist from the manipulation grip and my custom grip point issue being handled some other way (by me) be a good compromise? If not then I’ll try to follow your advice and implement a custom grip. Would I have to handle all sorts of multiplayer stuff in the custom grip that you do in the plugin? I’m sure to muck that up…
Thanks
EDIT: I already have a handle on my wheel where I place a VRGripP1 socket. I want the grip for point to be the manipulation grip I described above. Think rotating the large wheel/crank quickly, I don’t want any rotational hand input on the grip for the handle otherwise you turn the wheel like you do whilst gripping a steering wheel. is bad for things that aren’t steering wheels. Apols if I’m not communicating clearly.
Its injecting the hit location that is the problem (How to know where to put the constraint on the hand), there is no way to do it automatically off of the relative transform and I went through the effort of actually implementing it in the plugin morning as an optional in variable and I didn’t like it due to how much additional blueprint nodes it required as well as not being compatible with overlaps as they don’t throw a hit location. As far as wrist goes I don’t know for sure that people aren’t currently using that functionality and so I am loath to change it, more so when generally it doesn’t play into the standard interactions. However I WILL make a concession and add an additional grip type “ManipulationGripWithWristTwist” which will retain the classic functionality, with the original dropping the twist drive.
As far as multiplayer, custom grips will throw OnGrip and ReleaseGrip notifications on all authority clients for gripping, in the case of client side gripping that would be everyone, for server side it would be the server only. For custom grips the logic and what happens is all handled in the object being gripped (like Epics default template).