VirtualParent Lagging Transform Frames When Original Parent Moves Fast

[lxw404]

Describe the bug?

When using VirtualParenton an object that is attached to an avatar or anything moving quickly, the transform of that object will lag visibly. This may be related to: #151.

To Reproduce

• Create a sphere
• Create a box
• Parent the box to the sphere
• Delete the grabbable on the box
• Add VirtualParent to the box, setting its OverrideParent to the Root of the world, and its LocalPosition to something visible
• Parent the sphere to an active avatar
• Move around while observing the cube (more visible in faster locomotion like NoClip)

Here is a reproduction item that you can parent to your avatar (the box appears at Root <0,2,0>):

resrec:///U-LuxKitty/R-CFFE29695614772A190D34EFA2DDE153B7D070E5719A89FDCB5506D79C8894FE

Instead of parenting the object to your avatar, you can alternatively just move the sphere and then press Undo, and you should notice a visible jump.

Expected behavior

VirtualParent should probably ignore all prior hierarchy transforms and instead use the OverrideParent slot which is its new virtual parent slot, with zero jumping/stuttering.

Screenshots

Avatar attached:

2024-03-14_08-28-44.mp4

Undo:

2024-03-14_08-32-00.mp4

Resonite Version Number

2024.3.12.1169

What Platforms does this occur on?

Windows

What headset if any do you use?

Valve Index, Desktop

Log Files

VirtualParent Lag - 2024.3.12.1169 - 2024-03-14 08_07_44.log

Additional Context

No response

Reporters

LuxKitty

[Frooxius]

This can be expected behavior depending on what the UpdateOrder is of the VirtualParent - if it updates before its virtual parent updates, it will get the old pose.

Have you tried increasing the UpdateOrder on the VirtualParent to a larger number to see if this fixes this issue?

[lxw404]

This still occurs when changing the UpdateOrder. I have tried numbers ranging from $1$ to $999999999$ (max allowed), yet this does not seem to change anything.

[5H4D0W-X]

Disabling and re-enabling the items lower down the chain can fix update order problems, at the moment what updates when seems to be mostly arbitrary

[Frooxius]

What do you mean by disabling and re-enabling items lower down the chain exactly?

[5H4D0W-X]

@Frooxius when an item with a component such as a VirtualParent is parented underneath another item with another component driving its transforms, such as the components that make avatars move or dynamic bone chains, disabling the child (= lower down the chain of slots) and re-enabling it can sometimes fix issues with the ordering of when the transform values are calculated between frames. Specifically, @RustybotPrime has been having issues with values updating too late, but folding in his arms (which disables them) and folding them back out fixes the issues

[lxw404]

What is mentioned above seems to be a different issue entirely as I have not been able to replicate disabling any part of the hierarchy and re-enabling it to change anything whatsoever in this particular scenario. It would probably would be a good idea to get a minimal working replication example of what you are describing as a separate issue.

[RustybotPrime]

It hasn't happened since I integrated the system. The only lead I have is that it's actually based on how recent the flux was created or something. It seems silly, but some things like the order slots appear in the inspector are based on that and if it isn't then it seems completely arbitrary.

I had another instance of it yesterday when I was negating a transform with fieldhooks, but again now that I've saved and reloaded the circuit it works fine. I'll see if I can get an example but it might not even matter since once these items have been packaged together and spawned somewhere else the issue is gone.

On the topic of the original post though, this is a really common problem with a many of the transform components. VirtualParent, LookAt, RemoteConnectionPointDriver, and many other transform components all tend to lag a frame behind what they're connected to despite their assigned update orders. it's the whole reason I swapped from using them to flux for my IK. They seem to obey it to some extent as I noticed a change in behaviour when they were under a dynamic bone, but even if the order is properly staggered relative to each other they like to flick around.