SDK Bug & Feature Requests

SDK Version: 3.10.6. After setting up the basic setup for native face tracking (no "forward to animator" or anything like that), my avatar stoped syncing properly with remote users. During my test, I was with 4 to 5 people, and everybody was seeing the same behavior (it wasn't random between users). I remove all "Face Tracking" related on the avatar descriptor, reuploaded the same avatar, and all the toggles and parameters started to sync again. No VRCFury, D4rk optimizer or any 3rd party tools that modify the avatar during upload was used. 1st Video "FT ON": shows Avatar behavior with FT. 2nd Video "FT OFF": shows the avatar after removing all FT related from the avatar descriptor and reuploading it. Picture showing the setup on the SDK.

What happens Two related problems occur under certain conditions: 1) The "Use All Tracking Keys" checkbox works only at certain Inspector widths. 2) The left half of each field value does not respond to clicks when the Inspector is wide. See the attached image 1. Conditions This happens when the inspector of components placed below the VRCAvatarDescriptor assigns to EditorGUIUtility.labelWidth . This typically happens when a component has some multi-value fields (Vector, Rect, Quaternion and others) or fields with a custom PropertyDrawer or DecoratorDrawer since Unity internal code for them assigns that, but custom inspector code can also do it. In some cases, the issue does not occur even when these conditions are met, so there may be additional factors, such as Unity Editor internal timing or internal Inspector ordering. I have not been able to find reliable reproduction steps. It seems most likely to happen right after adding such a component to the Avatar Root, but I don't know whether this always reproduces it. Known components that meet this condition and are likely to be added to the Avatar Root: All AAO: Avatar Optimizer components (<=1.9.21) (PropertyDrawer) VQT Avatar Converter Settings (as of 3.0.3) (PropertyDrawer) MA Mesh Settings (as of 1.18.7) (multi-value field) Components that also meet this condition but are unlikely to be added to the Avatar Root: Unity Collider components (multi-value field) Workarounds a) Collapse inspector for components below VRCAvatarDescriptor. See the attached image 2. b) Move the VRCAvatarDescriptor component to the bottom of the component list. c) Click the horizontal position where checkboxes on other components are drawn, rather than the position where this checkbox is drawn. See the attached image 3. d) Component inspector developers can prevent this problem by setting EditorGUIUtility.labelWidth = 0; after drawing their component (example: [5]). Note that this does not work in PropertyDrawer s, because Unity's internal code sets EditorGUIUtility.labelWidth after your PropertyDrawer runs [4]. Cause VRCSDK 3.10.6 added AvatarDescriptorEditor3.CreateInspectorGUI , which simply wraps OnInspectorGUI in an IMGUIContainer , and this causes the problem. When Unity creates its own IMGUIContainer for an inspector, it uses a closure that does many things before and after calling OnInspectorGUI [1]. The most important of these are EditorGUIUtility.ResetGUIState(); [2] and EditorGUIUtility.hierarchyMode = true; [3]. The missing ResetGUIState() call causes the unclickable checkbox and the unresponsive left half of field values. Additional Notes VRCSDK 3.10.6 has problem that label area is narrower than that of other components. The cause of this problem is the missing hierarchyMode = true . [1] https://github.com/Unity-Technologies/UnityCsReference/blob/2022.3.22f1/Editor/Mono/UIElements/Inspector/InspectorElement.cs#L623 [2] https://github.com/Unity-Technologies/UnityCsReference/blob/2022.3.22f1/Editor/Mono/UIElements/Inspector/InspectorElement.cs#L659 [3] https://github.com/Unity-Technologies/UnityCsReference/blob/2022.3.22f1/Editor/Mono/UIElements/Inspector/InspectorElement.cs#L667 [4] https://github.com/Unity-Technologies/UnityCsReference/blob/2022.3.22f1/Editor/Mono/ScriptAttributeGUI/PropertyHandler.cs#L191 [5] https://github.com/anatawa12/AvatarOptimizer/pull/1816

Accessing Animator.parameters is expensive. AnimParameterAccessAvatarSDK clones the full list quadratically because it uses the getter inside a loop of the list. Reading this.animator.parameters into a temp variable once fixes the delay entirely.

Right now we have to set the eye rotation values quite high to get decent eye movement using eye-tracking after the recent native face tracking update. Due to having high values, now players without eye tracking have to deal with somewhat extreme movement which can go against the creators intent for the avatar. It would be good if we could instead be able to decide separately the rotation values for when eye tracking is enabled and disabled.

Affected avatar (Private) avtr_ddf6704e-bfb2-4c04-b8fc-1a8483876073 Load into avatar and enable Clothing/Select Clothing/Shirts/Mips Shirt Switch out and then back into avatar Have an observer join Enable Clothing/Select Clothing/Haku (which disables the other outfit) Local will see the outfit switch to the Haku, remote (the observer) will see both outfits remain enabled. Notably, this avatar worked fine in live until I copied the native face tracking setup from another avatar. Edit: It may also just be from uploading with the beta SDK, since I did those steps in one go I have heard reports of my toggles breaking like this in other worlds, but the world I tested in was https://vrchat.com/home/world/wrld_3641b8d9-04da-4ee4-8b06-966ca097b1a3

I want to be able to lose precision for the local user for radial menu items, to keep consistency with the remote user, this is for body customization options that will use very low precision. Ex. If the parameter width is 8 bits, the radial should move in steps of 12.5%

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

Despite this toggle becoming available when selecting the Bar effect, and the option's tooltip saying it should work, it doesn't Checking the code of "Packages/com.vrchat.base/Runtime/VRCSDK/Sample Assets/Shaders/Mobile/ToonStandard/Dependencies/AudioLink.cginc" reveals that indeed, the bar effect does not care about the "use mask" toggle, while the scroll effect does Is quality control really that hard?

Creating a prefab asset of an avatar that uses Eye Gaze Mode set to Both sometimes sets the eye bone rotation in that prefab to the ones defined on the EyeLookDown rotation state Not sure how to reproduce this reliably as it seems to happen only sometimes when opening the project. Affects sometimes only some prefabs but not others.

Issue: The current Advanced Parameters are set based on the sender with the closest proximity to the receiver. This makes sense for most of the advanced parameters but I would like to argue that Constant Contacts could benefit from being able to return a combination of matching tags from all currently contacting senders, not just the one with the closest proximity. Specifically, there are cases where you may have multiple senders in contact range you want to get the tags from but the limitation of only grabbing the tags from the closest sender forces you to continue to use multiple stacked receivers the old fashioned way. Usecase: In the attached screenshot is an example of where this could be useful. Multiple Receivers are needed in order to detect multiple contacts within range. i.e. all the fingers and hand contacts on a hand. A single Advanced Parameter Reciever would only detect and return the tags one of the 6 contacts on a hand. Another usecase I've seen in the past was a Contact based PVP system where each damage zone needed an additional receiver for each damage type. Multiple damage sources could be affecting a damage zone at a time so the new Advanced Parameters would also fail here as again they would only prioritize the closest sender. Hypothetical Usecase. Say a user has a sword that can switch elements. They have a SharpWeapon contact that is always active cause it is a sword, but also have fire, water, etc. contacts that they toggle on/off as they switch elements. A receiver with the Collision Tags Advanced Parameter currently will likely only return either the SharpWeapon or the Element contact but not both. (In this case it be solved by including the SharpWeapon tag on each of the element tags but the underlying problem still remains)