I’m using the mannequin skeletal mesh for a VR Body mesh, to be controlled with the head and arms from HMD transform and motioncontroller transform. Everything works out well, and the IK works well, but consistently the skeletal mesh is 1 frame behind my motioncontroller models.
So here’s the details:
I’ve got an Anim BP that has editable variables that are used directly in IK solver inputs for both arms. Everything is ‘fast track.’ I have a blueprint-inherited version of my C++ Character, which simply copies the world locations and rotations of two “HandOffsetComponent” sceneComponents which are children to the motionControllerComponents into the said variables in the Anim BP instance. Finally, I have a C++ Character class that the blueprint character inherits from, which does some extra logic on those handOffsetComponents and in some cases will attach them to other things for animation purposes. However, in all cases, even when the handOffsetComponents are parented to the motionControllerComponents, there is noticeable lag between the controller models (which are also parented to the motionControllerComponents or held objects parented to the handOffsetComponents; the object always moves one frame ahead of the skeletal mesh’s hands. In C++, I also call Super::Tick(dS) later in my tick function after any arbitrary reorganization or movement of the offset components.
In attempting to fix it, I have tried:
Every possible permutation of tick groupings between the Character and the SkeletalMesh
Registering two separate tick functions in my Character class, one pre- and one post-physics, and permuting my blueprint copying function through there
Scoping through the engine code with breakpoints, I verified that SkeletalMesh is ticking later in the frame, before render and after the character tick functions, so I do not believe tick ordering is the issue
Switching the IK solvers to component space, and offloading the relative transform calculations to the Character Blueprint
This is currently a game-breaker for me, as I rely on getting out BoneTransforms during my character’s tick in order to drive game logic, such as when interpolating the hand position to pick something up that is in a hand’s focus. Not to mention that I also run a feedback loop on finger IK to be able to constrict the fingers in order to see if an object has enough purchase to grab, which is working 1.5 frames late because of this, and causing fingers to produce erratic end placements. Please let me know if you have any solutions for this.
Can you tell me if you have “Disable Low Latency Update” enabled? I was talking with one of our VR guys and he mentioned that this kind of lag can be fixed by Disabling (box unchecked) that option.
thank you for responding so quickly. I had to finish implementing a module before I was able to compile and try your fix. Setting that flag has removed a significant amount of the lag, but unfortunately a small portion of the lag still persists. [Here is a video of the lag in action.][1]
After doing a bit of digging I was able to find that this appears to be a known issue. I have provided a link to the public tracker. Please feel free to use the link provided for future updates. Thank you for your time and information.
Hi, I think you misunderstood the wording on my comment, when I said that I “enabled it” I meant that I set bDisableLowLatencyUpdate = true; for both controller components. Which means that this is not relevant to my issue. I have edited my comment to provide better clarity.
Leaving bDisableLowLatencyUpdate=true should have some lag present (as low latency update is now disabled…and that’s actually what you want enabled). UE-32642 was reported correctly, but appears to have caused some confusion because of the double negative wording of the boolean.
From what I understand, you SHOULD see less lag with bDisableLowLatencyUpdate=false than with it set to true. UE-32642 reports that you still see significant lag with it set to false, which shouldn’t be happening.
and I will keep investigating this, but this is more his realm than mine.
Thanks for responding. For further clarity: the latency in question isn’t between a player’s motion and the actions in game, it’s between the game’s reported orientation of the motioncontroller and the animBP’s animation graph (IK solver).
I understand that disabling low latency update will cause the final SteamVR motioncontroller orientation to be fixed to where it was at the beginning of the frame. In other words this means the physical position of the player’s hands will be different from in-game by a few milliseconds. This is totally fine with me. The problem is that for some reason when I copy the transform of the motioncontroller into my relevant hand end effector transform (done in pre-physics tick) in the player model animBP, it doesn’t seem to update the animBP pose before render. It is consistently one frame behind. I just want the hands of my animBP to match up with the position of my hand components, and that doesn’t happen with either low latency update turned on or off for both hands.
I’ve looked into the flow of the engine, and it seems that the particular skeletal mesh’s updatePose gets called just before render happens. Which means that for some reason, the logical flow:
(SteamVR plugin updates motioncontroller location) → (set hand target in animBP) → (update animBP’s pose)
results in the animBP taking the hand target from the previous frame, and producing a pose to render for this frame that is out of date. Unfortunately I have no way of debugging the information passed in with the animation blueprints, as there are no symbols in VS 2015 breakpointing those delegates, and you can’t breakpoint in an animation graph.
I have another quick question for you. If you attach the object that you are wanting to follow the hand/controller to the motion controller, does this one frame offset still occur?
No it does not. That’s how I detected it in the first place: I have attached the motioncontroller mesh to the motioncontroller component, and it moves ahead of the IK update. Also I attach objects that I would like to grab to it, and they move ahead by a frame as well. Please see my video I posted in comment above: [][1]
Hi Rudy, just letting you know that I haven’t forgotten about this. I’ll be uploading a sample for you by the end of the week. Thank you for your support!
We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will follow up.
If you check the link to the public tracker. You will see that this issue is still unresolved. Please feel free to use the link provided for future updates.
This answer really got me out of a bundle, when setting ik targets on a that was a child of a vehicle, setting tick group to “during physics” elminated the jittering and latency I was seeing on a skeletal mesh. Much appreciated!
Literally fixed all my issues as well. I had all IK bones and their children lag behind any animation of the skeletal mesh it was attached to via component to socket. ONLY the animations were affected, but not worldspace updates, which was very odd to me. Changing the Parent meshes tick to ‘post physics’ made everything perfectly sync up! Thanks a bunch!
![113138-2016-10-31[1].png](https://d3kjluh73b9h9o.cloudfront.net/original/4X/4/5/b/45bcd8f23406649c91a17130b5417634f39bbb3c.png)
