VR Expansion Plugin

[Fnordcorps]

There are two options for that, since I don't know what everyone will want I left it open ended.


1. You can turn on bSkipOverlapFiltering in the properties which will make it just use collision settings for pressing.

2. Or you can override the IsValidOverlap function and filter however you want to replace the default functionality of things attached to the controllers or held by them.

Default functionality is there to prevent body parts from just pressing buttons all over generally, but obviously yes in cases like yours you would want to change the defaults.
Both options can be done in c++ or BP.

 // Skips filtering overlaps on the button and lets you manage it yourself, this is the alternative to overriding IsValidOverlap
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "VRButtonComponent")
bool bSkipOverlapFiltering;

UFUNCTION(BlueprintNativeEvent, BlueprintCallable, Category = "VRButtonComponent")
bool IsValidOverlap(UPrimitiveComponent * OverlapComponent);

Hi, thanks for this - so I turned on the SkipOverlapfiltering option in my buttons and I get some strange behaviour that I cannot work out. If I start my game and try and push a button with my fingertip, the buttons now move but freeze at what (I think) is the depress distance and will not move/interact again. However if I start a game, hit the buttons with the Grab Sphere part of the hand mesh first, the fingertip collision and buttons work perfectly/repeatedly afterwards?

Ideally I only want the fingertips to be able to interact with any of my buttons but that is currently beyond my blueprints knowledge! (still learning)


EDIT**** Would'nt you just know it - 2 minutes after posting this (after a day of trying) I worked it out - I had collision events set to on for a button shroud I had underneath the pushable button object which was interfering with the collision. Turned off collision and it works fine now. Will leave this comment in case it helps someone else! - Buttons not working as expected - check your collisions!

[Fele]

sorry if this has been asked before, but does the openVR expansion plugin support replicating hand tracking over network?
either with the UE Oculus Branch or the plugin from fsheffer?

[mordentral]

sorry if this has been asked before, but does the openVR expansion plugin support replicating hand tracking over network?
either with the UE Oculus Branch or the plugin from fsheffer?

It does so with the openvr index tracking, currently there is no extension to that for oculus as i'm waiting to see if they adopt the openXR microsoft hand skeleton extension, which would be ideal as all offerings would be rolled into one api then.

[Benjamin Paine]

Hey Mordentral!

I'm looking to add some grip strength interactions to some objects, for anyone that has controller capable of reading as such. I have no issues getting the values, my question is - what would be the best way to read the values in the object? My first inclination was to add a float variable to GripMotionControllerComponent.h and update it whenever I read an axis value - this works perfectly, and I'd imagine it would be perfectly fine to read this in TickGrip, but my only issue with using TickGrip is that in order to do so it seems I'd need to always use custom grip collision types, and thus lose the lovely base interactions. This is more of a minor inconvenience than anything, but an inconvenience nonetheless.

Since I can't rely on users having a grip axis, it's not going to be anything gameplay-affecting, just nice little easter eggs / alternate input for world interactions - so I imagine it doesn't need to be replicated (as long as the resulting actions, if needed to be, are.) I'd love a flag of some kind in the grip interface, default false, that allows me to signify that it should always tick the grip - or potentially an event that can be triggered against interface objects like an FVROnUpdateGripStrength_OneParam(float, GripStrength) Of course, if there's an effective way to do this now, please let me know!

Thanks a ton!

[Fele]

Thx mordentral

Your plugin prevented me from a lot of struggle while setting up a network for oculus quest with replicating HMDs.

Right now I am replicating controllers and I would like to replace them with Hands, but I am a bit lost.

At least for me as novoice unreal user it's pretty hard navigate to the version/feature/plugin/sdk maze - and to make the basis work.

I was hoping you (or some elsemelse could point me into the right direction for the least painful way to set this up.

I upgraded to UE 4.25 because I thought it generally would be better for handtracking... But there it starts with chosing between the Oculus branch (with native support for hand tracking) or the official release + the plugin from fsheffer.

And on top of that, both 4.25 (official and oculus branch) lead to an immediate crash when I launch the app on oculus quest... (Still trying to figure out why...)

If I understand your answer correctly it works with your plugin, but right now I am not sure what else is needed. And would it be also possible to stay on 4.24 which for me works more stable at the moment...?

Thanks

[mordentral]

Hey Mordentral!

I'm looking to add some grip strength interactions to some objects, for anyone that has controller capable of reading as such. I have no issues getting the values, my question is - what would be the best way to read the values in the object? My first inclination was to add a float variable to GripMotionControllerComponent.h and update it whenever I read an axis value - this works perfectly, and I'd imagine it would be perfectly fine to read this in TickGrip, but my only issue with using TickGrip is that in order to do so it seems I'd need to always use custom grip collision types, and thus lose the lovely base interactions. This is more of a minor inconvenience than anything, but an inconvenience nonetheless.

Since I can't rely on users having a grip axis, it's not going to be anything gameplay-affecting, just nice little easter eggs / alternate input for world interactions - so I imagine it doesn't need to be replicated (as long as the resulting actions, if needed to be, are.) I'd love a flag of some kind in the grip interface, default false, that allows me to signify that it should always tick the grip - or potentially an event that can be triggered against interface objects like an FVROnUpdateGripStrength_OneParam(float, GripStrength) Of course, if there's an effective way to do this now, please let me know!

Thanks a ton!

The object can poll the controller itself from tick or timer, or you could update to the held object from the controller, either works, no need for CustomTick at all.
If you place it in your character your animation blueprint can sampling holding character and use it or whatever.

[Benjamin Paine]

The object can poll the controller itself from tick or timer, or you could update to the held object from the controller, either works, no need for CustomTick at all.
If you place it in your character your animation blueprint can sampling holding character and use it or whatever.

Hah, here I was trying to find something complicated, the simple solution was the best one. I'll enable tick on the object when it gets held, then disable when it's dropped, and just read in the regular old tick. Thank you!

[CokeKuma]

In tests those guys were hiding invisible colliding bodies that are constrained to the controllers, then offsetting the pawn based on how far away the body is from its target location on collision, that is probably the easiest method to conceptualize how to go about doing it, then you can move to more stable iterations.

Its not a difficult concept to achieve if you think about it. Can do it with locking on to surfaces and reading positional differences as well (their hands lock on to the top of the surface when starting to climb, then they read the positional difference in that video and offset the player, the arms are not physics driven), or running fully simulated arms and reading wrist to controller differences, or for that matter, from held objects being stuck on things and reading where the hand is and where it should be.

If you really wanted to get involved you could also make the player based on an actually simulating body that is forced upright and use constraints from the hands to move it around directly when against objects, somewhat like lone echo.

Also the plugin doesn't support "physics body / gravity", its a character controller, all interactions are faked. Its not actually simulating on the physics scene, just being moved around in it as a kinematic actor.

The answer was very helpful. Some of the features shown in the video were reproduced.
But one more feature seems to be needed. Can gravity simply be added to the climbing mode provided by the plugin?

[mordentral]

The answer was very helpful. Some of the features shown in the video were reproduced.
But one more feature seems to be needed. Can gravity simply be added to the climbing mode provided by the plugin?

Add a constant downward force, that is all that gravity is, your issue is that you would have to account for it to avoid wobbling.

I'll also note that in the very latest patch, ALL movement modes accept the custom input, including falling.

[Fele]

Not sure what's wrong here: I set up a VR Pawn with replicated motion controllers, two quest controllers and the oculus hmd, represented by the UE Matinee camera.

1) I added a static mesh as child of the replicated camera component and copy/pasted the matinee camera from the camera component.
2) when I change the static mesh to another mesh, ALL visual representations of my motion controllers disappear in my own VR view and also for the other player in the network.

Am I doing totally wrong which breaks everything or is this a bug?

Instead of the static mesh component I also tried an "optional rep static mesh" but that didn't help...

[NebulyDev]

In tests those guys were hiding invisible colliding bodies that are constrained to the controllers, then offsetting the pawn based on how far away the body is from its target location on collision, that is probably the easiest method to conceptualize how to go about doing it, then you can move to more stable iterations.

Its not a difficult concept to achieve if you think about it. Can do it with locking on to surfaces and reading positional differences as well (their hands lock on to the top of the surface when starting to climb, then they read the positional difference in that video and offset the player, the arms are not physics driven), or running fully simulated arms and reading wrist to controller differences, or for that matter, from held objects being stuck on things and reading where the hand is and where it should be.

I also want to achieve what CoceKuma wanted too. Could you please provide some more details on how i would go about getting this working?

[thelazylion]

So a little feedback on the inherited mesh in the vr character... Montage seems to work fine.

Though, for some reason, replacing the inherited mesh with ugrippableskeletalmeshcomponent, for some reason only exposes Vr grip/mesh settings..
: Super(ObjectInitializer.SetDefaultSubobjectClass<UGrippableSkeletalMeshComponent>(ACharacter::MeshComponentName))

Used this to replace the inherited mesh with the grippable one.. However it no longer provides the "isheld" function or any other functions or events either. Placing a grippable skeletal mesh right next to it, has all the vr related functions working correctly though..

This also occurs in the "grippable character" class... Cant pull any grip functions off the mesh..

Is this by design or am i missing something on how to fix this?

Current workaround is just to pass the inherited mesh into a variable reference, and call the functions from there, a bit of a hassle to go back and change references but not that big of a deal for now.

[mordentral]

Not sure what's wrong here: I set up a VR Pawn with replicated motion controllers, two quest controllers and the oculus hmd, represented by the UE Matinee camera.

1) I added a static mesh as child of the replicated camera component and copy/pasted the matinee camera from the camera component.
2) when I change the static mesh to another mesh, ALL visual representations of my motion controllers disappear in my own VR view and also for the other player in the network.

Am I doing totally wrong which breaks everything or is this a bug?

Instead of the static mesh component I also tried an "optional rep static mesh" but that didn't help...

You don't even have visual representations of the motion controllers in that SS, ticking on showing the display component for them won't load them in multiplayer for other clients and there is no static mesh attached to them there.

[mordentral]

So a little feedback on the inherited mesh in the vr character... Montage seems to work fine.

Though, for some reason, replacing the inherited mesh with ugrippableskeletalmeshcomponent, for some reason only exposes Vr grip/mesh settings..
: Super(ObjectInitializer.SetDefaultSubobjectClass<UGrippableSkeletalMeshComponent>(ACharacter::MeshComponentName))

Used this to replace the inherited mesh with the grippable one.. However it no longer provides the "isheld" function or any other functions or events either. Placing a grippable skeletal mesh right next to it, has all the vr related functions working correctly though..

This also occurs in the "grippable character" class... Cant pull any grip functions off the mesh..

Is this by design or am i missing something on how to fix this?

Current workaround is just to pass the inherited mesh into a variable reference, and call the functions from there, a bit of a hassle to go back and change references but not that big of a deal for now.

Its a side effect of how BP handles overriding default base classes, its why I made a seperate VRRootReference variable when I overrode the capsule component to use as a direct reference. Casting to a grippable mesh and storing the pointer will work just fine, its just the BP graph not understanding class substitution fully.

[Magneto]

It's been a couple years since i looked at this and it looks like it's progressed a lot so nice work. However i never did end up using it as it seemed a bit bulky and confusing when all i wanted was a solid fps ready template. I was wondering if the guides could now be updated to be more clear and the plugin get more simple plug and play options for turning on and off features?

Am i supposed to compile the plugin and go through all this visual basic setup and stuff or can it just run as a off the templete demo?

To be honest i miss some of the old templates we had as they were simple blueprints. The basic unreal vr template doesn't do standard teleport (stick turning is weird) and comfort snapping otherwise id use it for basic projects. Though really id love it if now vr is more mature someone could create a solid template with most of the standard options, weapons and hand physics of half life alyx.