[1472][SDK3.6.2-constraints.2] Major issues caused by the referencing of constraint sources and real time editing of anim files (likely cause of the slowdowns)
available in future release
lackofbindings
I saw some reports by other creators that their animation paths relating to VRC Constraints were becoming broken and screenshots showed paths like
managedReferences[5546551713573896202].Weight
which immediately made me go to investigate. For comparison, the built-in constraints system store references like m_Sources.Array.data[0].weight
(clearly by index).So here was my test:
- Initial conditions: Existing VRC Parent Constraint with two or more sources, as part of a prefab, one or more animations that animate the weight of those sources. This must be a child of a valid Avatar Descriptor, and the animation(s) must be in an Animation Controller that is set as a playable layer in said descriptor.
- Delete both sources from the parent constraint.
- Observe that the animation channels are deleted from the animation files(s) by the VRCSDK in real time!!
- Revert the changes we made to the component (or add back the sources manually if not a prefab).
- Observe that previously existing animation channels do not return!! They are lost forever, and all related anim files are left in a permanently broken state! (In some cases the first source continues to animate properly at this point, hence the example needing more than one)
Now from here lets assume you had git or some other version control already set up:
- You see the anim files are now broken, you go to revert the changes to the anim files in git.
- Observe that the paths are now broken (yellow). The IDs of the constraint sources no longer match up. They were automatically re-generated in the component, and do not count as a prefab override so were not and cannot be reverted)
- The anim files are now in a different but still permanently broken state. The only way to resolve this is to find-and replace the IDs in the prefab/scene files with the original IDs from the anim files.
To me, all of this seems like a massively over-engineered and extremely delicate solution to a problem that didn't even exist.
All this just so you can drag to reorder the sources in the list?
Also it seems extremely likely that this real-time scanning-and-editing of animation files is whats been causing the widely-reported slowdowns with this latest SDK, (and why said slowdowns disappear when the avatar descriptor is removed)
.Also personal note: I am very against the idea that my files are being silently edited in real time by the SDK, this should never be the case, and certainly not in such an unstable state.
Log In
This post was marked as
available in future release
Dexvoid
tracked
Dexvoid
This is a consequence of how MecAnim handles animating array elements.
Based on our experimentation, Unity animation clips cannot modify raw values inside arrays. Instead, the objects in the array must be referenced directly by the animation bindings, which allows MecAnim to write directly to that specific object. The internal object identifier for the source that's being animated is what you're seeing in the square brackets after "managedReferences" in the binding name. While we would much rather have serialized bindings by name like you've suggested, please understand that we're also working within the limitations of the engine that VRChat runs on. Unity constraints do not have this issue because they are a native part of the engine, and therefore seem to receive special treatment on the native side to let animations for them reference source array elements by index rather than by object ID.
It's clear that this isn't working well with the community, so we're now investigating alternative solutions to this problem. This is likely going to involve collapsing the sources array into a flat list, which would also impose an upper limit on the number of sources a constraint can have. For those curious, the Unity package Animation Rigging is an example of a system that takes this approach to get around this exact problem - you'll find that you can't assign more than eight sources to any of the constraint types in that package.
We are open to suggestions on what the sources limit should be for VRChat constraints.
lackofbindings
Dexvoid I'm way outside of my area of expertise here, but is it possible to control the managed reference ids at all? I found this in the docs https://docs.unity3d.com/ScriptReference/Serialization.ManagedReferenceUtility.SetManagedReferenceIdForObject.html what if you could set the reference id to a nice constant value based on the array index?
I'm sure no one likes the idea of setting a limit on the number of sources, but whatever solution that we settle on I think it's important that it doesn't involve any real-time editing of animation files (even if we change nothing else lol). If a proposed solution needs to edit any files please make sure it can do so non-destructively on build/play.
Dexvoid
lackofbindings Thanks for the suggestion! We can certainly experiment with this.
The objective would be removing the need to refer to a specific instance of a source on a constraint in the animation clip. Once this is possible, it would no longer be necessary to automatically correct the IDs in the animation clip since the bindings would be constant anyway. (Clips can still be automatically updated by the conversion tool triggered by the user, which it needs to do in order to fully convert an object from Unity constraints to VRChat constraints.)
Smash-ter
Dexvoid would that method be tested in the next beta SDK release?
lackofbindings
Smash-ter this has already been solved! check out SDK3.6.2-constraints.3
Smash-ter
lackofbindings it's capped at 16 sources for the time being
bd_
This kind of "feature" will also behave poorly in conjunction with systems like Modular Avatar or VRCFury which merge additional animators into your avatar, and perform their own animation path rewriting...
Myrkur
I also have to agree strongly on the two points made here
To me, all of this seems like a massively over-engineered and extremely delicate solution to a problem that didn't even exist. All this just so you can drag to reorder the sources in the list?
and here
I am very against the idea that my files are being silently edited in real time by the SDK, this should never be the case, and certainly not in such an unstable state.
This seems very much like a solution in search of a problem and is implemented in the most delicate and unmaintainable way possible.
Myrkur
I noticed this too but wasn't sure were to report it, the "managedReferences" property used only seems to be referenced properly to the actual constraint property if its actively on the avatar standard animator controller (as if you were creating the animation and recording), if the animation is being modified outside of the avatar's context then it will revert to showing the "managedReferences" this shouldn't be the case and really disrupts many prefabbed workflows that require modifying animations as you are now unable to tell which source you are editing.
Ive attached two images that show this, the first image has the avatar selected with the animation added to the animator, and the second is just selecting the animation from the project asset folder.
lackofbindings
Myrkur Yeah I saw this as well, though it seems to be only cosmetic. If you check the anim file yaml it is always stored as
managedReferences[…]
Myrkur
lackofbindings yeah I went digging into the SDK to find out a mitigation for this as editing these animations outside of avatar context makes it very hard to know which source you are modifying, and when it comes to working with prefabs such as making avatar content with VRCFury or Modular Avatar it really slows down the workflow having to reattach every animation.