huh? The capsule “triggers” overlaps on trigger volumes and the like just fine. Its the hands that have issues, like all other things, they don’t sweep and update their attached components the same way.
The new movement system fixes the capsule “spamming” overlaps in itself, since its not actually moving normally the engine never compares last and current overlapping components and sends start and stops every tick.
Regardless, yes, you should likely have a collider around your head anyway if you intend to use it for things like view darkening or disabled pushback.
I’ll try out the new system after work. What should I look out for? What are the biggest changes?
We’re currently implementing movement and climbing from the plugin into our game and it has been working great
But maybe I should wait until the improved movement system is done?
For some reason your original demo 4.18 the capsule wasn’t triggering overlaps. I set the head cube mesh to overlap and it worked.
What is the best way to have the hands trigger overlaps? That seems like an important feature. I set the hands to generate overlaps as well, but then I couldn’t close the drawers after opening them. I was also climbing the table.
I’m getting seemingly intermittent crashes after having upgraded a 4.17 project (based on the VRExpTemplate) with 4.18 cl:002602841e01.
When I updated it I just made a copy of the 4.17 project under 4.18. Deleted the Intermediate folder, replaced the old VRExpansionPlugin folder with that of the one from the aforementioned cl. Built it and got no errors.
Tried to launch the proj and got a “couldn’t find the VRexpansionPlugin extension” error or something. Deleted the Intermediate folder again, and did a Rebuild instead. time it worked but now I often (2 out of 3 times playing in PIE) get error:
LogOutputDevice: Error: FMatrix::InverseFast(), trying to invert a NIL matrix, results in NaNs! Use Inverse() instead.
Here’s the error w/ the callstack:
After upgrading I made these BP changes:
removed the spawn actor for the player character (in the SteamVRcontroller) because I was getting 2 player characters spawning in.
changed the closest secondary/primary grip nodes to closest grip nodes.
I’m likely doing something stupid, but thought I’d post it here just in case. Probably unrelated to the plugin.
I’ll try to update to the latest version of the 4.18 and see if that fixes it.
Edit:
Actually, it looks like I’m on the latest master 4.18. I’ll give the new cool character refactor version a go.
Edit 2: Nah. The latest character refactor cl didn’t magically fix it. Maybe it’s just a 4.18 bug or change that’s making happen as it wasn’t happening on 4.17.
Hi really new here and would appreciate a bit of help. I’ve got the prebuilt plugins showing up in 4.18. I created an VR basic Pawn ( Vr actor pawn is not showing up ) No controllers are spawning, and I’m 1-2 feet off the ground. I’m building a fitness focused movement system so I’ve done my share of work, math and analytics on my end I swear, haha. It’s the learning curve of the engines that is slowing me down. Any help is appreciated thank you!
I’m having trouble, can’t seem to make a new VR Character Actor, it doesn’t show up, just the VR Basic Character. When I load the character my playspace is up off the ground and there are no motion controllers.
I doubt you were on the latest character anyway, it isn’t Master it is still a beta branch.
Looks like it is coming from the NonAuthorityMinimumAreaRectangle class which is a direct copy of Epics node but without authority locks. There is no NAN check and your HMD must be passing in an invalid bounding box for the tracked area.
Thank you. I am slowly working out these little confusions.
I got another one for you… Is there a way to limit the player to only two locomotion types? I would like them to only be able to choose between Armswing or Teleport. I have tried removing the other ones from the “Movement Mode Enumeration” but ended up with tons of errors. Clearly, that cannot be the correct way.
Hey, thanks a lot for the reply even though you’re so busy.
I initially built the latest master cl and just updated the closest grip nodes (in my old modified 4.17 template character) that were erring out. Was getting crashes so then I tried the latest char. movement refactor cl. Sorry, I wrongfully assumed that the movement improvements were happening on the backend, not in BP… What I should have said was that I tried both master (4.18) and latest refactor (4.18), not the latest char. I apologize for that.
I’ve no idea. Maybe. How does one lose calibration or check that it’s been lost? I googled around for info on it but didn’t find anything related.
I’ll try to run the Steam VR setup/calibration thing again. Thanks a lot for the help!
Edit: It looks like it got fixed just by running the simple SteamVR stand-up calibration. Thank you so much for the heads-up! And sorry for posting it here.
One way to toggle between your desired two movement modes (assuming you’re using the VRExpTemplate character) is by slightly modifying the Cycle Movement Modes function in the Vive_PawnCharacter.
I pm’d you a screenshot of a modified right hand movement mode select. That’s the only modification I made. I left the enum as is. It just switches the mode to Armswing if the current mode is teleport, and to teleport if it’s not teleport.
Like Kuso said, you can modify the cycling, or just directly control it yourself and unlink the cycling all together. The latter would be better, the cycle is only there to demo in the template and you likely want the side grips for more in a normal game.
LeftHandMovementMode and RightHandMovementMode enums are pretty much all you need to set to choose movement modes.
Is there any way to disable / get additional control over the “VRWall Slide” / Repulsion mechanism in the VRMovementReference?
I’m looking to have a little more control over what happens when the character collides (mainly to minimize nauseating effects for first-time users). For now, I was thinking about using a teleport away from the Wall/Object…
One possibility is to use a non-VR character, but then I need to build the build the pawn all over again - and I lose the possibility to control in-game how collision is handled…
Well you can always change the walls to overlap and do whatever you want with it then… There is also walking collision override for the root capsule which lets you only have wall collision during locomotion but during walking without locomotion you can walk through / into the walls as it uses a separate collision channel with that enabled.
The upcoming 4.18 beta branch that overhauls the main character also adds events for when the wall sliding begins and ends to allow people to customize further as well (blanking vision, adding stable boundaries so that the slide doesn’t feel personal, ect).
As far as disabling, you already have all of the control you need for that, the character follows all std engine collision protocol, I don’t touch teleport back from penetration or other solutions like that as there are many ways to handle it and they don’t fall into my ideal for the plugin.
Generally it isn’t an issue unless you are having tables or blocking obstacles provide pushback, which I would suggest be avoided. Really only walls should be doing that.
Hey there,
we decided to implement plugin for the vr networking in our already working project. We use the distance between the MotionControllers to set the WorldToMetersScale to scale us up and down. After implementing plugin we have strange behaviour on . When the controllers are close together (10cm) it works as it was previously. When the controllers are further away (~60cm) the controllers start to jitter horribly and the scaling goes back and forth what causes the jitter to accumulate into a complete mess. Moving the controllers close together causes the jitter to stop. When the scaling is initialized with the controllers far apart (>60cm) the jitter starts immediately, even when the controller are not moved.
So whatever state of scaling we are in: Controllers far apart = horrible jitter, close together = everything normal.
The MotionControllerComponent is within the PlayerCharacter. Everything attached to the Component is in its own blueprint (like the controller mesh).
Another very interesting part: Just adding a SkeletalMeshComponent as child to the GripMotionControllerComponent within the PlayerCharacter prevents the jitter, for what ever reason (it has to be a SkeletalMesh!). It even is enough to add just one SkeletalMesh to one GripMotionController to prevent the jitter on both controllers.
So it looks like it has something to do with the childs of the GripMotionControllers. I had a look in the code and found UGripMotionControllerComponent::FGripViewExtension::GatherLateUpdatePrimitives which gathers the whole child hirarchy of the GripMotionControllers and adds those to the LateUpdate stuff when a child component is a PrimitiveComponent. I put in a breakpoint at the beginning of the function, but it never fired. So the function seems not to be called at all what makes it even more strange.
What is late update stuff? I came across it now multiple times, but could not find an direct explanation. In terms of Unity engine seems to be a tick(?) that comes up last within the engine loop, just before rendering. In terms of Unreal seems to be the TickGroup. Some more explanation about would be nice.
UE4 gathers scene proxies and late updates them in the rendering thread by re-sampling the controller / HMD location there and applying the difference to their visual location (not game location) since the game thread last moved them. is because the rendering thread is a frame or so after the game thread and you can get significant offset with fast movements in VR in that time.
Prior to 4.18 (.17 of my plugin because I implemented it early) they were using a method that caused some thread thrashing and jitter like what you were seeing. It mostly happened when moving at high velocities but I could see if happening with scaling the world as well.
TLDR: 4.17 of my plugin, or 4.18 of the engine likely fix for you, it should be because of badly managed cross thread variables that they had in the late update system. However you can also just turn off late updates on the controllers during scaling operation and it should also fix it.
I don’t know if you had late updates off in your original controllers? They should be using the same logic for the late update as epics in the 4.16 branch. Its possible that there is something missed, but I just went back over some of those areas recently.
Edit I have it on my 4.18 list to run down through the world scaling again since they made changes to how the components handle it (post 4.16). I can probably take a look back at the older version too.
Thanks for your fast reply.
Right now we can’t upgrade as we rely on a plugin that is not up to date yet.
I tried calling SetGripLateUpdateSettings with “LateUpdatesAlwaysOff” but it did not fix it.
As you describe it the late update is just a rendering thing. If so, why does it seem to mess with the location values on the game thread?
No turn the late updates off on the controllers themselves, also DOES it mess with their game thread values? You said that the hands were VISIBLY shaking, I would assume that if the game thread values were off that the scaling would shake as well.
Because that would be an entirely different thing.
Edit Just saw you say that the scaling goes back and forth…mmmm
Are you using the simple character? The code base is the exact same for the controllers between epics and mine EXCEPT for when using a simple character as I have to pull back the controllers in that case.
I’m using the AVRBaseCharacter. Only thing I’m doing is I have a child of AVRBaseCharacter that Destroys the controllers and replaces them with a child of GripMotionController (doing that in the constructor). Those child controllers just override TickGrip witch I made virtual. I don’t want TickGrip to be called, as we don’t use the grip stuff and there seems to be a lot of code in.
As everything is working when attaching a SkeletalComponent to the controllers, I assume I did nothing wrong there.
Flying:
We also need to fly the whole time of the game in multiplayer. However I’m not able to get the clients to “fly”. They are always falling down. I try setting SetMovementMode and SetReplicatedMovementMode on server and client to “flying”
Edit: Was a bit to fast. Managed to make the Clients “fly” but for now they are always reset by the server. Will have another look tomorrow.
Base character is just a proxy between the two different characters so that I can reduce code duplication (climbing and special flags that both need), it isn’t a fully functional VR character in itself…
Also TickGrip only does things when there are gripped objects, having no gripped objects it early’s out of the loops and only does two transform Gets. If you are making a child of the original controllers you will also want to be totally sure that you aren’t calling Super::TickComponent or you will start getting weird issues.
Edit I’ll note that while looking into the world scale thing today I didn’t find any issue with that hitch on 4.18, however I did find that Epics new late update system screws over the motion controllers location if the world scale is not 100.0f.
