VR Expansion Plugin

Mmmmm, is for a specific reason? Like you wanted the advanced physics options of the interface on a procedural mesh? Because generally you can grip sliced objects without the interface with the naive gripping nodes, the slicer in the template level has that.

I don’t mind adding a procedural mesh grip, it just needs some more work than other things since when it actually gets sliced the body changes and has to be re-initialized. Also it would be better to actually have a slicing function that directly creates a grippable version instead of creating a proxy and copying the mesh data over.

Just want some more information on why you needed it before merging the files from the PM you sent me or iterating over them with some improvements.

Edit Also for the record things like I am more than willing to do, though i’m sure it was helpful to do it yourself to learn how the grippables are modified.

Is there anything exposed for detecting what VR controllers the client is using? such as knuckles or vive wands.
i see the GetHMDType but not sure if thats purely headset related

You can directly poll the controller name from the SteamVRAPI, I have a node for that in the latest template that specifically checks for knuckles. Valve seems to feel that you shouldn’t need to know the name in the end and that you should check the TrackingLevel of the controller to deal with differences between them, something that is understandable in theory, but currently not good enough as we still need controller offsets to sync up gripping transforms.

I’ll likely make a controller specific steamVR node that returns the controller type eventually, kind of waiting to see what the name of the index controllers will be in the end so right now its a direct string query.

thanks, found the node in the template.
I noticed in the OpenInput plugin the Get finger curl and splay data dosnt seem to have any data in the splay array, is it still in the works?

Splay doesn’t exist on any current controllers, there are three levels of tracking in OpenVR, Estimated (most controllers), Partial (Index with curl), and Full (none currently, but things like gloves and/or leap motion or AR pose tracking could provide).

Index controllers don’t have a splay element, so the splay values will always be empty.

The hand action has a var “SkeletalTrackingLevel” that you can access to read out, I will need to make a function that retrieves that eventually as well. I’ll note that the module is fully compatible with the official Valve plugin, when that one is installed mine turns off the input handling and just acts as a layer on top of it to allow for the gesture / replication / full body posing.

Pushed a new commit to both repositories:

Added some prelim physics changes and replication improvements prior to the more major physics changes coming down

Patch notes here:
https://vreue4.com/patch-notes?secti…eanup-06-13-19

so they are just using the capacitive touch the thumb buttons and trackpad to create the splay then i presume.
Currently using a finger solver for controlling them on other controller types and gesture determination from the fingers, im just using the curl data from the openinput to feed into that for index controllers.
How does your gesture determination work if i may ask? mine currently uses the curl values to determine a gesture, looking to improve it if possible.

Same thing, just with thresholding and a database to store values / mirror them. I was running off of pure transforms before they started inferring the curl data from them.

So I figured it out and it works for what I need however I had a question. Im trying to add functionality where the character can bend over but the whole body doesn’t follow not sure how to set that up since all I have is the hmd and vive hand controllers. Do I need a waist motion controller? Or is there a way around that. For some reason it wont let me post the reference images. it says they are too large. Let me see if I can add them later.

You need to handle a waist estimation with the IK. Good IK systems should already have that?

Oh okay well I followed some tutorials to get me far so not entirely sure how to get a waist estimation going.

Hi ,

I noticed while using a vrbuttoncomponent that if you alter the relative transform of it at runtime when you interact with it it hops back the place it was set originally. I haven’t tested it in depth (or looked at the code) but I was animating a button using a timer to pop up only when you stand on a platform and found that when I set the transform of button component to its “down” position in blueprint viewport what I describe above would happen. But if I set it to its “up” position then override it at runtime it works as I would expect.

That is because it is storing its current state so that it can handle lerping and resting positions and the over depth past the click depth.

You need to make sure to SetButtonState as well so it knows its new position. That being said, you can SetButtonState with bSnapIntoPosition as False and it will lerp itself into the new state for you so that you don’t need to manually do it.

I’m not sure if I didn’t explain myself well or if I just don’t understand… but having looked at the code I believe the reason I was getting what I was is that I was animating the relative transform of the button component to its parent so the buttons *I**nitialRelativeTransform *was no longer correct when the button was pressed. There was a panel you stand on which triggered moving the button up from the floor to hip height and also setting its opacity. So I don’t believe I could have resolved my issue using SetButtonState. I think I could have called ResetInitialLocation or probably better to have childed the button component to a scene component and altered the transform of the scene component instead.

I can’t remember if I read somewhere that you actually said to not alter the relative transform of the buttoncomponent itself and to move a parent around if you wanted to move it now I come to think about it…

Ohhh, yeah the way you wrote it, it sounded like you were trying to reset the button, not move its entire location. When finished moving it, ResetInitialLocation will make the current location its “base” location (unpressed), then you can SetButtonState to your preferred state. Also moving a scene component parent of its will work as well and not require you to use any special logic, so it may be preferrable.

Hi ,
I’ve been noticing some problems with using a remote grip by way of the custom pivot components in multiplayer. I set it up as you did in your video Brief update - YouTube using the built in laser to set the location of the grip component. I also added thumb stick control so it can push or pull the actor away from you. My problem is that the client’s offset grips never seem to update on the server.

Example: I grab object on client 20 feet away using laser beam. Client is fine, but on the server it teleports to the hand. Also the thumbstick setting the grip component location just doesn’t work on client, I can see the grip sphere move, but the actor won’t. I know you said the grip components are not replicated and I’ve tried to set it up but nothing seems to work and my blueprints are turning into spaghetti. I have a hackish way to force set the location if a client is using it, but it ruins grip functionally and seems messy.

I know problem is probably too specific, so I totally understand if I don’t hear back. I just feel like there is a simple way to update the location of the clients grip components that I’m totally missing.

Has anyone run into horrid stuttering issue in the hmd? it seems to happen if the world scale is anything but 100.0.
Cant find whats doing it, all the transforms of the pawn and components are not actually changing from the stutter
video link: Stutter - YouTube

You need to set the pivots on all clients / the server, you also need to replicate that you are moving the custom pivots. The pivot can be ANYTHING so I can’t really replicate that for you, and replication in engine is one way, server-down.

You need to tell the server that the client moved the pivot (or move it on the server and let it movement replicate down to the clients). Right now you are just moving it on the owning client only and it is staying in the same spot on everyone else.

Is that in multiplayer and did you not change world scale on the server as well? Because the CMC would report incorrect locations then.

no it wasnt multiplayer, it seems to be related to nav mesh, if i delete the nav volume and restart the editor it gets rid of it