VR Expansion Plugin

[rohezal]

Is there any way, to download the template and load into the unreal 4 engine editor without compiling anything? Doesn't matter if 4.16.1 or4.15.2. It doesn't matter which commit I try it just says missing plugins [*VR_Example*dll] . When I start my own project it works. Or is there a way to download the blueprint code for climbing / teleporting objects / picking up / showing hands (or controllers) seperately?

[kusogaki77]

Is there any way, to download the template and load into the unreal 4 engine editor without compiling anything?

rozehal,
You went through the image-based tutorial yeah?

I know of 2 people, with not so much experience at all in UE4, that have verified it got them building.

I'll post a link to a pre-built VR Package Template that runs with UE4 4.16.1. (I think latest is best, so I'll make that and send you a gdrive link.)

[mordentral]

rozehal,
You went through the image-based tutorial yeah?

I know of 2 people, with not so much experience at all in UE4, that have verified it got them building.

I can PM you a link to a pre-built VR Package Template that runs with UE4 4.16.1. (I think latest is best, so I'll make that and send you a gdrive link.)

The pre-packaged binaries as long as the date on them isn't too far from the templates last update should also work, the downside being that the template also uses the sessions plugin which has its own pre-packaged binaries....

Is there any way, to download the template and load into the unreal 4 engine editor without compiling anything? Doesn't matter if 4.16.1 or4.15.2. It doesn't matter which commit I try it just says missing plugins [*VR_Example*dll] . When I start my own project it works. Or is there a way to download the blueprint code for climbing / teleporting objects / picking up / showing hands (or controllers) seperately?

You can actually directly transfer the uassets over, but it would be a little difficult to know the exact ones you want.






BTW for everyone else, the reason that climbing and movement "logic" are not built into the code and are handled in blueprints is two-fold

#1: I wanted anyone to be able to play with and modify how they work easily so they can get it working how THEY want.

#2: For blueprint users it gives them examples of how to achieve different things, for c++ users, they can convert blueprints to c++ at will anyway.

I have been considering building some common objects into a c++ "pack" in the plugin, like levers and buttons and dials and the like, haven't made up my mind yet.

[kusogaki77]

The pre-packaged binaries as long as the date on them isn't too far from the templates last update should also work, the downside being that the template also uses the sessions plugin which has its own pre-packaged binaries....

You can actually directly transfer the uassets over, but it would be a little difficult to know the exact ones you want.

Sheit, sorry to make it seem the way I mentioned was the only way.

[MENTION=428570]rohezal[/MENTION]
If you just want to see the plugin with minimal effort, dgaf about anything else, and just want to move around like a VR madman climbing on stuff and scaling/gripping/flinging isht (none of which you made) to kingdom come, here's a link to a prebuilt template for UE4 version 4.16.1.

[tiagovignatti]

I have been considering building some common objects into a c++ "pack" in the plugin, like levers and buttons and dials and the like, haven't made up my mind yet.

It's the only practical and viable way I see for developers collaborate to the plugin. I absolutely support this idea!

[kusogaki77]

Sorry to sidetrack this.
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 this 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 this? 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.

[mordentral]

Sorry to sidetrack this.
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 this 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 this? 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 this and the object will be orientated incorrectly otherwise). It may be that Epic finally fixed this 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 this.

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.

It's the only practical and viable way I see for developers collaborate to the plugin. I absolutely support this idea!

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.

[Starkium]

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

[mordentral]

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

[Fantasifall]

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

[mordentral]

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

Done, smallest commit yet

[Haircut]

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

[mordentral]

The low gravity mode feels amazing. Thanks again for making this 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, this 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 this 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.
This 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 this 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).

[kusokuso1]

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 mordentral 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 this, 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.
(This 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; this is so I can play item-specific grab animations)

[mordentral]

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

Do whatever you want with those, those are just epics template hands, they don't have anything to do with the plugin and so they shouldn't receive any changes from me.

② 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 this, 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)

I don't know how you intend the specialty items to work, if they block normal interactions when active then you can just insert logic for them prior to the normal gripping code, this way they are handled if active and if not then it falls back to the normal gripping and climbing logic.

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.
(This 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; this 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.