VR Expansion Plugin

Sorry to sidetrack .
I got a socket prob.

tl;dr
Custom Static/Skeletal Grippable Mesh actors aren’t oriented/positioned exactly mirrored in each hand, but the Template Gun_Base is.

What things might I need to make sure are good?

I have custom-made hands, and equippable items (all made in Blender). When I use them hands to pick up the grippable static mesh gun_base in the template, the gun orients perfectly! To be more specific, the position is just a little bit off, but it’s off identically so for each hand, which I assume means it’s because the pivot point on my hand is not the same as that on the mannequin hands in the template. That’s totally cool. The important thing here is that they are angled/oriented perfectly regardless of the hand I grab it with; the gun always faces forward exactly at the same angle.

I’m not getting same, exactly mirrored orientation on my own grippable static mesh and 2 grippable skeletal meshes though. The static mesh’s orientation is perfectly mirrored along UE4’s Y, but its location isn’t if I move the socket’s Y position (it’ll be distanced good from one hand but not the other).

The skeletal meshes are more effed. I spent about 6 hours today mucking with the root’s roll of the 2 skeletal items, tried orienting the entire armature in the exact same direction as that of the GunBase mesh (facing down -Y in Blender, +X in UE4) but still no luck.

Anyone familiar with Blender/UE4 reimporting know how to fix ? I think it’s likely a roll or root/armature rotation problem, but I’m not sure. I do know for a fact though, that reimporting fbx in some cases doesn’t implement all changes between the fbxs (specifically in regards to Anims, possibly armatures too I’d suspect).

The Static Grippable Mesh position prob is maybe because the origin/pivot is off from. I’m away from the work computer for the weekend (Japan time). I’ll be able to try any other solutions 2.5 days from now.

The hand meshes don’t have anything to do with the objects location, the object is mapped on to the controllers zero point itself, where your representation of the hand is from that is entirely up to you, you can move your hand position relative to the motion controller at any point.

As for skeletal meshes and root bones, due to a bug with physically simulating objects and root bones I have to add the root bones extra rotation into physics grips to support objects with a rotated root (the engine does not account for and the object will be orientated incorrectly otherwise). It may be that Epic finally fixed and I was unaware of it but you seem to be saying that the preview of the mesh is incorrect not the gripping of it for .

If you get a chance and want to pass me a PM with one of the problem Static and problem Skeletal meshes I could look at them.

The whole point of how I handle it currently is to avoid requiring people to orient meshes a specific way in order to work with the plugin.

I just dislike the concept of closing off gameplay element modifications from strictly blueprint users, the main goal of the plugin is to be a flexible back end, not a rigid front end as well.

Edit I guess they could still implement them in blueprint as well if they wanted custom ones, and I could leave the current blueprint versions intact.

Ok I see teleportation and navigation are technically the same thing, but where are you doing the magic for the navigation part???

ExtendedSimpleMoveToLocation()

I ported some of the AIControllers navigation functions to the VRCharacter and setup client side navigation for VR (engine by default is server sided navigation only). If the movement mode is set to navigation when it ends the teleport arc it calls ExtendedSimpleMoveToLocation instead of teleport, its the SimpleMoveToLocation node with a few more features/options.

The out of body movement does the same thing except it also switches the camera during the movement part, I added a “NavigationEnded” event that fires when navigation ends (end of path, error, ect).

Just a reminder that you wanted to expose “Set Crouched Half Height” as has not been implemented by Epic. Thanks!

Done, smallest commit yet

The low gravity mode feels amazing. Thanks again for making so accessible!

Let me know if you run into any issues with it, it was a very quick and basic conversion of flying movement to get it going.

Pushed a new commit to the plugin, is a few days worth of changes and sadly will cause c++ users to make a change (GripInterface has a new function).

I intend to leave it as is for awhile for bug fixes with movements and grips due to some sweeping changes made here, during down time from the major
systems I will likely be converting the interactible components from blueprint to c++ and making them cleaner (the button already saw considerable cleanup
recently in blueprint).

Post the interactibles conversion I would like to get to some of the feature requests. The Force constraint setting was actually a feature request, I implemented it first
due to being close to another one of my wishlist items already.

Plugin changes



Added advanced physics settings for the interface, by default they are turned off
however when turned on they can be used to change constraint settings beyond the normal
acceleration based with stiffness/damping for angular being auto calculated.

One use would be to change it from an Acceleration based constraint to a force based one.
 would create better behavior with manipulation grips in some scenarios as well
as offer a method of delayed / weight simulated grips (would likely need the custom
angular stiffness and damping set then as force values for these are far higher than
acceleration values).

I have plans to add more features to the advanced settings in the future. When deactivated the
additional grip property costs 1 bit to replicate. When activated the replication cost
is dependent on what in it has been enabled.

I have been wanting to expose the physics settings more to the user and  is probably the best
way to do it (Like auto center of mass setting on grip). I would love to merge the normal stiffness and 
damping into the same structure but it would break many projects so it may never happen.

C++ Actors/Components using the interface will need to implement the new getting function
for the advanced physics settings (if ever merged it would replace the separate stiffness
and damping functions instead).

Now using a nearly check for better precision safety when checking for replicated changes for
stiffness and damping.

Added optional angular stiffness / damping setting to the SetGripConstraint blueprint function

Added visual and editable indicators to grip interface settings that are controlled by a boolean
(IsInteractible / UseAdvancedPhysicsSettings). To make it easier to work with them.

Made some WalkingCollision override changes to be more reliable and consistent as well as use
more custom logic and less hackish workarounds. Will need feedback on how it behaves now.

New ClimbingStepUp fixes (for VR Char only ATM) appear to help a ton with
step up issues. Adds a configurable variable to the StepUp settings that sets a seperate
threshold for when a capsule is considered within stepup range making it significantly harder
to accidentally fall back off backwards when stepping up. Should not be increased beyond the radius
of the capsule (is noted as such on the variable comment).


Hello,
(I’m running a version of the plugin from a couple weeks ago.) I opted to convert all of my user equippable items into grippable skeletal/static meshes so to retain all those checks and balances implemented.

tl;dr
2 Questions:
① Is it OK to consolidate the Grip Enum (Hand_State_Left/Right) with my custom one? Afaik, it looks like that Enum is only used for the Hand Blendspace1D.

② I want to change the gripping controls such that climbing is enabled when pressing triggers while hands are Empty, and those special Equipment Grip Interface objects I made are equipped/Unequipped by pressing Thumpad face button 1/3 (respectively). In order to accomplish , would it be best to do separate grip checks (each of which are modified checks based on all the logic in the GripOrDrop flow) for all of those buttons? (Once an item is equipped, I have that actor do all the trigger_value and grip pressed checks in order to execute item-specific behavior)

Currently, gripping/ungripping in the Vive_Pawn is based (solely?) on the triggers. I want to change those gripping controls a bit without getting rid of those C&Bs, but I’m a bit lost on how I should go about it.

My VR_char has 4 things parented to holsters on different parts of the body (RR-style).

I want to accomplish the following 3 things, but I’m afraid I’ll mess up the current Checks that are already in place.

①Enable gripping&climbing only if Trigger is pressed while hand is Open.
( works perfectly currently, using the default grip logic, but it conflicts/overlaps with the 2 things I want to do below)

②Equip holstered item if Face Button 1 is pressed & Hand_State is Open & Grab Sphere collision is overlapping & Item_Type == Empty.
lerp its pos/rot back to the calling hand’s socket, set Hand_State is Grab & Hand Item_Type = <itemtype>

③Unequip item if Face Button 3 is pressed & Hand_State is Grab & Hand Item_Type != Empty
Then lerp its position back to its holster, set Hand_State is Open & Hand Item_Type = Empty
(The reason why I want equip/unequip on the thumbpad is so I can use the trigger and grips for item-specific actions when an item is equipped.)

I gave each Equippable item an Equipment interface that just monitors its respective Equipment’s Holster position/ID and sets the respective hand Item_Type; is so I can play item-specific grab animations)

First two answered in the quote above, rest below.

I set up the button mappings in the input settings, you can feel free to change what goes to them, or directly link new logic instead. You won’t be able to do anything super custom with the template without deleting and refactoring a bit, its just the nature of the beast. Even if I consolidate every little bit of the logic into functions that you can just call from subclassed characters there will still be instances where its not going to work with something special you are doing, the template isn’t gospel, it is supposed to be an example of how to set up things, there is a lot in it that you can likely remove and the gripping logic is based around just pick/place/use interactions.

If you have really custom button mapping that you wish to use then you’ll want to copy the VRCharacter and work off of the copy instead of the original or a subclass. Then you can delete and rework as you wish without losing your references, it will also let you compare with future examples.

Thank you for all the info and sorry for the long post.

The Try to Grab Object function’s got Drop Object and Grip Object funcs. If those funcs take care of the unparenting/parenting of objects and Gripped Actors array, along with some other magic, wouldn’t that mean I have to/should use them any time I drop/pickup an object; otherwise that’d basically defeat the purpose of me making them grippable? I was thinking I could just call drop object w/ Simulate unchecked before doing a custom function that returns the Object to the holster. Just want to make sure if that is one, not so bad, way to do it.

On a side, I just now found out that the BitBucket vrexpplugin url changed (used to be “vrexpplugin”, now it’s “vrexpansionplugin”). affects the Specific Commit walkthrough a little bit.

<anyone>
I followed the Update Plugin instructions (Safe Method version) gave a while back (on Page 25). fsr, the .uproject won’t generate new project files (.sln). Anyone else seeing problem? Running 4.16.1 and trying to update current with Master VRExpPlugin as of a couple minutes ago.

Edit: Nevermind, I figured out that deleting Advanced Sessions was the cause of the .sln not getting generated.

Yeah you should use those if you want to grip/drop an object with the plugin (have it in the array and replicated). For traditional grips like parenting you don’t have to use them.

GripObjectByInterface()/DropObjectByInterface() will grip/drop an object and auto fill in its grip settings by querying the interface.

As for the name, it shouldn’t have ever been the shorthand, are you sure you weren’t working off of a branch that you made? Regardless I corrected it in the setup tutorial.

Got it, thanks.

Shoot sorry, is all my bad. I got the right screenshot for the plugin url, but for the copy-pasteable url I copied the url for the template and removed “template” from it, wrongfully assuming it was the only difference.

When updating the plugin, should we not delete the Advanced Sessions folder?

The template depends on that folder for the server browser, so no I wouldn’t delete it. You can manually remove it by editing the .uproject file and then delete the server browser object if you really want to.

First off, thanks for making the plugin! It’s extremely useful. I’ve been trying to get the VR replication to work for ages and is perfect.

Quick question, do you need anything further to get the multiplayer working? I sent a copy of the template (with a few minor changes) to my friend, but we haven’t been able to find each other. We start SteamVR, open the project in the editor, host a server, and try to search for each other. So far, no luck. We’ve been able to connect using the Advanced Sessions plugin on a different project in the past, though. Not sure why we can’t connect here…any ideas?

SteamVR Home currently breaks the steam subsystem in UE4, you’ll have to disable home currently in order to find servers (the subsystem will literally not load with home active).

Little overview of how to use the new VRButton c++ class.

…not used to using a single screen in ue4, i forget to switch windows a lot, don’t mind it.

Hmm, that wasn’t it. We both opted out of the SteamVR Home Beta in the SteamVR settings and still couldn’t find each other. Do both of us need VS2017 for 4.16 to work properly?

Oh sorry I missed you saying that you were running it in editor. That won’t work, you need I package the project and send that to him. Steam doesn’t load in editor previews aside from standalone and even if it did, it would technically still be different builds and autofiltered by epics subsystem.

Ah! Alright, I was hoping it would work without packaging the whole project. I’ll try that tonight.

Thanks for the help!