[1471] VRC Constraints cause jitter with contacts and physbones
available in future release
SenkyDragon
Please re-evaluate running VRC Constraints in the proper update order to eliminate the jitter on physbones and contacts. This is the chance to fix this.
Log In
SenkyDragon
Please consider https://feedback.vrchat.com/feature-requests/p/do-not-limit-contacts-to-60-updates-per-second as part of this. Arbitrarily not receiving contact updates on some frames wrecks havock on triangulation and velocity blendtree calculations. I'm not really even certain why there's a frequency limiter in the contact manager to begin with.
Dexvoid
available in future release
FairlySadPanda
This has been shown off as having a fix in the works in the latest dev update; feels like maybe this should be promoted out of Tracked given it's a development ticket?
Chiimera
I found a post where someone previously did not experience jitter, but after the update/constraint conversion they are now encountering it.
Dexvoid
Chiimera: Issues need to be reported to us here on Canny with relevant avatar IDs for them to be tracked and investigated.
Chiimera
Would it possible to add an option in Phys Bones settings to forcibly run it after constraint evaluation, or to calculate before but apply motion smoothing after evaluation?
Thanks!
Dexvoid
Chiimera: As mentioned in the comment chain below, exposing an option for this is not ideal because there would only ever be a single correct solution for this avatar that should be determined automatically, so hiding this complexity from avatar authors would be preferred. Additionally, always running physbones after constraints would not address avatars that have physbones relying on constraints that themselves rely on physbones.
Dexvoid
tracked
This is a known issue that's been affecting VRChat for a while, but unfortunately it isn't as simple as moving constraints to run before physbones each frame, since that would break existing avatars that rely on physbones running first. Instead, individual physbones and constraints would need to be scheduled to run based on the dependencies between them.
Running our own constraints system opens up the possibility of fixing this. This is technically a pre-existing issue, so to help control scope, our focus for the constraints beta is on maintaining compatibility for avatars using constraints. Further improvements on top of that can be looked into later on.
Dor․
Dexvoid "since that would break existing avatars that rely on physbones running first" this argument was made multiple times, is there anything really stopping you from maintaining the current behavior for automatically converted Unity constraints and/or exposing the option to change the execution order?
Dexvoid
Dor․: If those avatars switch over to VRChat constraints in the future, they'll still need constraints to run after physbones. Providing an option for when constraints and physbones execute shouldn't be necessary since there would only be one correct solution for each avatar that could be determined automatically, and hiding that complexity from avatar authors would be ideal.
In short, there's a lot of different avatar systems that need to be handled carefully to avoid breaking any existing avatars! We want to avoid rushing in a solution in this beta to reduce the chance of that happening.
Dor․
Dexvoid "If those avatars switch over to VRChat constraints in the future, they'll still need constraints to run after physbones." which is exactly why exposing the setting would help, auto conversion could default to it, put it under Advanced and name it "Legacy execution order" or something similar and most people will never touch it if they don't need to.
Smash-ter
Dexvoid on the physbone side of things wouldn't it be better to have a transform property that can act as a way to ignore the player's root transform offsets that are culled from the rest of the hierarchy, making it the "anchor" it can ignore all the parents that are higher up in the hierarchy?
Dexvoid
These are good ideas. There are a few details around this problem that will take time to sort out that go beyond physbones and constraints themselves, so again, this likely won't be addressed in this constraints beta to control its scope and help make sure VRChat constraints release in relatively good time. I appreciate that this is an issue people are eager to see fixed though.
Smash-ter
Dexvoid I had a bit of a thought on this, and I'm curious if it'd be better if the freeze world thing was it's own component rather than a part of the constraints so the world freezing element could be handled differently compared to constraints.
Myrkur
also notice this with some of my friends public prefabs. more specifically with constraints alone, seems to be a general issue with update order for VRC-Constraints all together.