I’ll assume that you haven’t tried it yet? The default grip that every object uses unless you change it is a physics one that is blocked by geometry.
Hi,
I’d like to implement the VR Expansion Plugin’s climbing functionality into a project I’m working on. I’d like to use the motion controller pawn that comes with Unreal/ Looman’s VR Template level, though (its just simpler for me to read and work with, and I also want to maintain its grip animations and bones etc - additionally, I’m, on Oculus). How would you recommend I go about implementing the climbing functionality from the vive pawn character in my project?
Would copying the group of climbing functions and variables from the vive pawn character blueprint to Unreal’s motion controller pawn work? Or are there other things in the vive pawn character that aren’t specifically labelled “climbing” that functionality relies on? Any help would be very much appreciated.
(As you can probably tell, I’m not too experienced with blueprints – I’m comfortable working with materials, textures, and basic interaction/events, but less so with functions, components, etc.)
I saw several semi-related posts on topic in posts above (have spent hours crawling through the forum), but nothing that conclusively answered it, and maybe more importantly, the most recent of these posts came almost a year ago, and I’m sure some things have changed since.
Additional note: I’m still using 4.18.3.
Thanks so much once more (you helped me access a past version of template level via PM) for your excellent work on open source project.
is the best VR Plugin ever !!! Tank you so much !!!
One question: I play in editor, sometimes it’s show hands mesh, sometimes not (show vive controller). How to fix that!
There are a bunch of nodes highlighted in red in the character that implement steamVR’s auto model loading.
They are getting deprecated anyway when epic fixes the model loading on the motion controllers. If you delete the nodes that reference the procedural mesh it will keep just the mesh hands.
Well if you want multiplayer then no, you can’t really port it. If you just want single player, you still can’t port it directly as it uses a custom movement mode for the character, but you can take the general concept and apply it. Same BP nodes except instead of using the climbing input node, you just set pawn position instead.
That being said, it won’t have collision or step up or velocity on release, that would be up to you to implement then, the default template pawn doesn’t have that kind of movement logic.
Got it!
Tanks for the reply.
Ah, so you recommend using your vive pawn character and porting some of the more Oculus friendly features and animations/bones from the motion controller pawn to it, rather than the reverse (or what I initially proposed)? And I’m working on a single-player experience. The two forms of locomotion I’d like to include in it are teleportation and climbing.
Nah, climbing in itself is very easy to do, I was just warning that it would be positional only unless you implemented the rest yourself.
Although not sure what you mean by oculus friendly, the template is just a set of examples, the plugin itself doesn’t care what headset is used and the hands used in the template are the same, I just have them being overridden by default to show the model loading.
As for ease of use, yes, you are totally correct there :p, I wouldn’t suggest my plugin for people looking for a simple base, its for advanced implementations.
By Oculus friendly, maybe I just meant my-skill-level-friendly, lol, insofar as it’s straightforward for me to tweak some of the button bindings so the Rift’s “grab” button rather than trigger handles grabbing, while the trigger handles “activation,” etc. And all the while maintaining the appropriate grab animations.
For someone looking to incorporate climbing into their project, where would you point them to? Did you address in the Q&A video you did some months ago? Or is there a segment of the wiki you’d suggest concentrating on? I’m very much willing to learn, but unsure exactly where to begin. Any guidance would be very much appreciated.
My climbing is a custom movement mode, you turn it on, and then pass in the offsets you want, its used for more than just climbing, the general concept is just to get the hands difference from where you want it to be on the gripped object and then move the pawn to place the hand back there again. So if you were to custom code it for a base pawn, its just storing initial grip location on the object, and moving the pawn by the inverse of the CurrentPosition - InitialPosition (just initial position - current position also works as it already negates it).
Hi ,
Sorry I have a question again. I am using your plugin and added a skeletal mesh on the Vive_PawnCharacter with basic IK redirecting the hand location to my motion controller while I am holding nothing and to a socket on a static mesh while I am holding a gun (the static mesh).
I noticed the IK was slightly delayed when the motion controller transform was plugged in the FABRIK node and it is fine.
But severe delay occurs when I plugging in the transform of the socket on the gun static mesh and it is very noticeable.
The problem get worst when I am holding the gun and moving around the map with DpadHover movement and the hand absolutely could not stick with the socket transform.
Is there any way to let the hand keep up with the gun especially when I am travelling in the map?
Thanks in advance!
Thank you, got it. For anyone interested, ‘Add Spline Mesh Component’ is what to search the BPs for.
the held object is being late update transformed, you would have to disable late updates on the grip or the motion controller in general.
IK is being run in the game thread, which is 1-1.5 (or even 2) frames behind what late update does visually.
Also dpad movement means that you want to pull your animation offsets after the character movement completes, I am actually not very sure how animation graphs handle execution order (or if they even do).
Edit I’ll note that at least one other plugin user is already doing with the physics grips to block hands with the object itself, its a neat effect, but I would highly suggest ghosting the controllers when position gets out of sync so that players don’t feel hand eye disassociation.
Thanks for the quick reply!
What do you mean ghosting the controller? And for the blocking to occur with the object it mean I will have to make both bodies rigid and blocking each other by physics?
Another mesh attached to the motion controller that “ghosts in” (changes transparency) depending on distance from the IK hand.
And no, I meant the hand mesh/ik being moved with the held object means that when the held object is blocked by geometry that the hand will also stop (if you are using physics grips, which all grips are by default in the plugin).
Pushed some minor updates live to the repositories, have been looking into new gripping system concepts again so actual large systemic changes have been put aside for a bit.
Template
Updated the pixel density slider to show percentages and be 4 digit precision, helps people visualize
how to properly use the command.
Set the default example gun in the template to ignore gravity (in grip settings), hate the slight offset.
Added thumbstick deadzone variable to the vive pawn for sliding movement, the deadzone ability was always there
but I never made a variable for people to easily modify it (defaulted off 0.0f)
Started some touch profile input overrides, Template should have profile examples, been really busy
with backend work and didn't get around to it before.
Added a pre-check for bDenyGripping on client side before trying to RPC a grip request to the server, saves some
bandwidth.
Now using newer openvrhmddevicetype node at init to more cleanly detect HMD type in the template.
Plugin
Merged with LeverRepTest beta branch, should enable proper replication of initial lever RelativeTransform to clients.
Needs some more testing but will be ported to other interactibles once proven solid.
Post teleport move now uses the new setting for motion controllers that delays the teleport until the next grip tick.
ensures that the teleport uses the correct final transform and is post all character movements.
Per bone gripping constraint distance for auto dropping made to be off of the bones specific location,
not the root bones location. was missed when adding per bone gripping, could cause grips very far from the root
bone to auto drop if per bone gripping was enabled.
Exposed the physics constraint creation / movement / destruction to BP for custom
grips to make use of.
Would love to know more about VRLever component and it’s XY axis setting. When picking up only one axis to follow, current angle returns either positive and negative values, which are great for, for instance an input/controller mechanic. Whereas when going with XY Axis setting it will always return positive angle value no matter the rotation of the lever. I’ve noticed the comment in the plugin code, however is there a way to actually make it work so it’d return positive and negative values based on both X and Y axis’ ?
1 Like
Hello mordental,
I was working with a flat widget for my widget class and your laser is working great for selection of the button.
But I changed my widget to a geometry Mode Cylinder and your laser beam is colliding not the curved surface of the widget but a ghost invisible flat surface of the widget.
see here with the debug (in Blue) the endpoint is hitting the curved surface and your laser in red stop on that flat surface as if the widget was flat.
Do you have a solution for that ?
thank you.
XY setting returns the levers facing normal (seperate variable), and then the angle is the angle in that direction.
A singular angle can’t represent XY since X could be + and Y could be - at the same time.
way you can translate that 2D plane normal into a direction, and angle into a magnitude.
Edit
// Bearing Direction, for X/Y is their signed direction, for XY mode it is an actual 2D directional vector
FVector CurrentLeverForwardVector;
That variable to be specific, it is an FVector instead of an FVector2D to make using it simple (just multiply into other vectors).
The laser is hitting the collision geometry, there isn’t much to do there unless you override how the component generates its collision. You can fake it for cylinder ones by progressing the pointer forward but not sure that is worth it.
shows the collision on it if you are curious
https://i.imgur.com/1aQ5SA5.png