First thanks a ton for pointing me in the right direction with Yurinik’s patch for using more devices than the current Unreal SteamVR implimentation would allow. That’s working for me.
I have noticed another issue lately after I updated to 4.19 version of the template which I’m not sure was an issue before. At least I don’t remember noticing on a previous version I was using. I was noticing with my IK body setup which is driven by gripped motion controller components that there’s a very apparent jitter to other clients controlled characters, while my own character is smooth. is the same for all players. The owned character is smooth, and other connected characters are jittery.
With a latest version of your template just before your 4.20 work I was able to isolate the issue to a repeatable example with these steps:
-with VivePawnCharacter I enabled the steamVR representations of the controllers/trackers, and hid the other hands/controllers that come enabled with it.
-ticked on autoActivate for the netsmoother on the components (not sure if is necessary)
-I disabled late updates, and set the grip motion controllers to smooth replicated motion
-gripped motion controllers are set to netupdate rate of 60 by default
-packaged in shipping.
-Connected server/client from two machines.
-From here I’m noticing jitter on the gripped motion controller for the other connected character that i don’t see on my own character.
-To see if i could see the smoothing effect happening better, I played with the console command net pktLoss=50 to simulate loosing half of the packets so i could see what the client smoothing is doing better. The more the pktLoss the more the jitter is pronounced, and I don’t notice any interpolation happening.
Other things I tried:
-Changing the net update rate to really low percentage. makes the jitter more pronounced.
-Changing the net update rate all the way up to 100. The higher the update rate the more high frequency the jitter.
-Tried LAN mode, also the same
-Swapping to the Epic MotionController components has the same effect as net update frequency of 100 on your components. Which makes sense as it’s essentially full replication but no smoothing.
Right now, I’m not noticing any smoothing happening on the gripped motion controller components from the other clients point of view so I was wondering if something has changed with the smoothing setup that I need to account for, or maybe I have just had it set up wrong from the beginning, and am just now noticing.
Also, if I wanted to play with the network smoothing myself where/how would be best to do that? I noticed your lowpassfilter_rolling average, and lowpassfilter_exponential functions and was wondering how to swap between the different types of smoothing to try them out.
Sounds more like you have the hand/procedural mesh being replicated rather than the controller replication is messing up. Setting it to 100 htz shouldn’t require smoothing at all, so if it is still doing it then you have something wrong.
And the smoothing on the controllers doesn’t use a low pass filter, i’m not smoothing out jitter, i’m smoothing out between updates received based on the expected time between updates. And nothing has changed in the smoothing area since 4.16 or so.
Also the default MotionControllers DON’T have client up replication at all, so I can say that it likely is your hand / procedural mesh if you used theirs and noticed anything at all, since theirs isn’t even replicating up to begin with.
Edit What do you mean by jitter by the way? Do you have a gif or video of it?
You can verify that smoothing is doing anything at all by setting the update rate to something silly low like 5, and then viewing with and without smoothing turned on.
Ok, sorry for the false alarm. I also updated an IK plugin I was using when moving to 4.19, and didn’t notice they added replication by default so what I was seeing was double replication causing jitter. Then it was just a matter of me confusing myself with the Net pktLoss thing leading me to think the smoothing was the problem. Smoothing is working great, and thanks for the response!
Yeah…I have been suggesting to people for awhile now to turn off IK replication, several of the different IK plugins them use it and the VRplugin already handles that better (less bandwidth, smoothing, on the actual component) so its just doubling it up.
Since the controllers rep by default with the plugin the IK should just be client side entirely.
Heads up to people still on 4.18 or who don’t look at the logs, I added a warning in 4.19 about how the InteractibleSettings were going to be deprecated soon and to move away from them into custom gripped objects and the pre-made levers / sliders instead.
4.20 is when that deprecation is happening, they will be removed at the same time as I add a new system “GripScripts” that will have less overhead, more options, and is fairly easy to extend. GriptScripts will come with a built in script that emulates the original InteractibleSettings for convenience sake (and as an example), however the current settings that people may be using will be lost and have to be carried over.
The functionality of InteractibleSettings was essentially dead at point, with custom grips doing it cleaner and with less overhead, I haven been trying to find a good time to remove it for a few engine versions now, doing it alongside the addition of the GripScripts made the most sense to me.
Edit Grip scripts may actually be waylaid, currently they arent’ panning out like I had hoped.
ok so im a bit confused on the grip system with gameplay tags. and i couldn’t find any documentation in your wiki.
im trying to set up a common oculus system where the items are picked up on grip and dropped on grip release. triggers would be the use buttons. my test object is the gun which i love and have expanded on vastly to do all kinds of guns now, and flashlights or just socket griped pickups. its great code.
but i cant figure out the grip tag system.
i got kinda got it working. i added a grip input and set the tags for the grabR and grapL commented code and it picks up and drops correctly, but then i had issues figuring out how to properly rehookup the triggers so i can use them for use events.
can you please tell me a bit about how the grip tags system works and how i could use it for what i need.
In the example gun I have that shown, on grip it rebinds the UseButton to trigger and the drop button to Grip if the gun is held at the handle, if it is held outside of the handle then it retains the trigger grip/drop.
You can swap gameplay tags around live on objects to control what buttons they want for what actions.
The gameplay tags aren’t part of the plugin itself, the template does all of the control code for what the plugin does in blueprint and gameplay tags were the easiest method of allowing any object with any interaction for testing. The BPs are just calling the correct plugin nodes for grip and drop depending on the tag values and what button was used for the action.
However, if you really just want those actions you mentioned above, you can skip all of the code setting parts and in the objects default tags just set the following
And it will work like you want without live re-assignment, will grip and drop with side grip press, will use with trigger press, and end use on trigger release.
Hi , plugin is fantastic. We’re migrating our game over to it bit by bit, we’ve come across one thing that we can’t replicate with your plugin though -
We have a leaning system in our game where collisions at your feet prevent further non-roomscale locomotion, but the player can still use roomscale to lean over objects. So we can lean over railings or over worktops and tables, but are prevented from moving through them using controller movement.
With your plugin, HMD position seems to be locked completely to the capsule, so leaning over objects is impossible. Have seen in some places you mention a “neck offset” but we can’t seem to find any such option (perhaps isn’t even a solution to our problem?)
A perfect solution would be to have the capsule recognize steps and ramps and handle vertical travel with precision, but to only block the player on a horizontal plane past 40-50cm or some arbitrary value so there is some generous tolerance, and maybe as a back up have the camera position will fully block the player if they try to look through a wall or something. Is anything close to possible?
Anyway, help would be super appreciated for , since not being able to look / lean over objects feels very limiting. Hopefully it’s just something we’re missing, keep up the awesome work :>
Bump. I am also extremely interested on modifying the collision capsule in game. I use alot of climbing and leaning over ledges and tips for haveing a bit of leniency for passing thru certain objects in game would be awesome to know
I don’t intend to add officially myself as the concept in general is flawed, without a waist tracker the “lean” effect can be done just by the player walking forward, you don’t have any real way to actually require them to make the leaning motion. At that point there is no difference between an offset collision / no collision on the object and allowing “leaning”. Faking detection of a lean with head to floor and hand detection is impractical IMO.
And then WITH a waist tracker there is no need, the capsule will follow the waist instead and the problem doesn’t exist.
The neck offset is a value on the capsule that offsets it by a distance from the camera, you can modify it during runtime if you wish.
I had a working concept with a seperate capsule around the head and some logic to deal with the two, but I didn’t like what it required me to do for multiplayer and I locked the branch away back in 4.12 or so. Its on the very farthest back burner of my features TODO.
Also there is the WalkingMovementOverride collision option, it allows you to use two seperate collision setups, one for locomotion, and one for roomscale. So you can walk through objects like tables, but you can’t locomotion through them.
While I agree the concept is flawed without a waist tracker, VR hardware is so limited right now that workarounds are necessary to make up for the lack of tech :mad: Can only dream of full body tracking right now.
Anyway WalkingMovementOverride is more or less exactly what I was after, it works very nicely after some quick tests, thanks so much!
However you can also manually offset grips by OffsetTransformByControllerProfile the node, or manually doing that logic when using a slot grip, or using seperate sockets.
The latest is just that bOffsetByControllerProfile option on the motion controller itself which moves the actual controller to account for the difference.
Yeh. Leaning has always been dodgyin all vr. But i can look up whether or not i can turn on and off a collision channel mid game. If that works i can alow climing thru scene objects but not the world floor or environment walls. Then i can climb over the top of stuff a bit easier.
Speaking of which
? Is there a way to add collisions to my character that prevents movement other than my capsule. It would be cool to make the body smaller and not be able to phase my head into walls.
No, it is actually a significant level of overhead to perform the movement logic with more than one sweeping body. There is a reason characters in pretty much all games use a singular capsule for performant movement. Adding another one is a significant overhaul of the character movement.
As mentioned previously, I had a working method (the comments are still in the code here and there), but it was too expensive and hard to work into multiplayer character movement cleanly.
Also yes, you can turn off channel collisions at will on the pawn capsule.
