SDK Bug & Feature Requests

Unity version [2022.3.22f1] VRChat SDK - Base [3.10.6] VRChat SDK -Avatars [3.10.6] When multiple ContactReceivers with different CollisionTags settings are selected simultaneously, a bug occurs in which the CollisionTags settings of the last selected ContactReceiver overwrite the CollisionTags settings of all other selected ContactReceivers. This bug does not occur with ContactSenders. I tested this issue in an environment where no other tools were being used.

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%

Requesting a function for facetracking parameter behaviors to simplify mapping a tracking key from one range to another. Arity-5 version allows specifying both the input and output ranges: map(key, in_start, in_stop, out_start, out_stop) Arity-3 version assumes 0 and 1 as the input range (basically the same as lerp ): map(key, out_start, out_stop) Performs this equivalent operation: out_start + (out_stop - out_start) * ((key - in_start) / (in_stop - in_start)) I'd also suggest providing a version which additionally clamps the result to the output range, maybe called cmap . One use-case for this is to be able to easily remap tracking keys to bias them in certain ways while allowing the user's facial movements to still contribute to the expression's livliness. For instance, in a "Sad" blendshape set, you might want to remap the "BrowInnerUp*" tracking keys to the range of 0.7 to 1.0 to force a sadder look. How this function would be used to accomplish this example: Apply to Blendshape, "BrowInnerUpRight", Custom Blendshapes Set: "Sad" Expression: map(BrowInnerUpRight, 0.7, 1) It reads a lot better than (BrowInnerUpRight * 0.3) + 0.7 to get the same result and I don't have to work out the math for each range I'm trying to target. I foresee this also being used a lot to bias eye dilation/constriction for a lot of different emotions.

Summary When a Multi-Platform Build & Publish for a world is started from the platform that is last in the SDK's platform order (for example Android, with Windows and Android ticked), it never finishes. It builds and uploads Android, builds and uploads Windows, then switches back to Android and builds and uploads it again, and keeps repeating until the user stops it. The cause is VRCMultiPlatformBuild.ShouldContinueMPB . When the starting platform is also the last in the list, it returns true on every return to that platform, because that branch assumes the platform has not been built yet (as in the avatar flow). The world builder has already built it at the start, so the end-of-run check in SetUpNextMPBTarget ( MPBBuiltCount + 1 == MPBPlatformsList.Count ) can never become true. Environment Unity: 2022.3.22f1 VRChat Worlds SDK: com.vrchat.worlds 3.10.3 VRChat Base SDK: com.vrchat.base 3.10.3 Content type: World (Udon / UdonSharp) Platforms ticked: Windows and Android (PC + Quest) Editor open on: Android. The loop only happens when the run is started while on Android. Files involved: VRCMultiPlatformBuild.cs (com.vrchat.base, Editor/VRCSDK/Dependencies/VRChat) and VRCSdkControlPanelWorldBuilder.cs (com.vrchat.worlds, Editor/VRCSDK/SDK3) Steps to reproduce Open a world project with the Editor's active build target set to Android. Open the VRChat SDK Control Panel, Builder tab, and tick both Windows and Android for a multi-platform build. Press Build & Publish. Wait while the SDK builds and uploads Android, switches to Windows, builds and uploads Windows, and switches back to Android. Expected: the run ends when it arrives back on the starting platform, and the "Multi-Platform Upload Finished" notification shows. Actual: the SDK builds and uploads Android a second time, then Windows again, and so on until the user cancels. Root cause The platform list is [Windows, Android] and MPBInitialPlatform is Android, so the starting platform is also MPBPlatformsList.Last() . Tracing the session state through the run: Android (start), count 0: StartMPB sees initial == last, so it does not enter Building. BuildAndUploadMultiPlatform still builds and uploads Android because Android is in the list. Android, count 1: SetUpNextMPBTarget picks Windows, increments the count, state = Switching, switches platform. Windows, count 2: ShouldContinueMPB returns true (initial != current). Windows is built and uploaded. SetUpNextMPBTarget picks Android and increments. Android (back at start), count 2: ShouldContinueMPB reaches if (MPBInitialPlatform == MPBPlatformsList.Last()) return true; and returns true instead of finishing. Android is built and uploaded again. Android, count 3: the SetUpNextMPBTarget end check needs MPBBuiltCount + 1 == MPBPlatformsList.Count , which is 3 == 2 and false. It switches to Windows and increments again. From step 5 the count only grows past the list length, so neither exit is ever reached: not the isMPBFinished = true path in ShouldContinueMPB , and not the early return false in SetUpNextMPBTarget . The initial == last branch in ShouldContinueMPB and the BuiltCount + 1 == Count check in SetUpNextMPBTarget look designed as a pair for a flow where the starting platform is skipped at the beginning and built last (the code comment says this "can happen for Avatar builds"). In VRCSdkControlPanelWorldBuilder.BuildAndUploadMultiPlatform the only skip condition is !_selectedBuildTargets.Contains(EditorUserBuildSettings.activeBuildTarget) , so a starting platform that is in the list is built immediately. That leaves the count one ahead of what the end check expects. This pairing is an inference from reading the code, not something confirmed by running the avatar flow. Suggested fix End the run when it returns to the starting platform and every platform in the list has already been built. In ShouldContinueMPB , the initial == last branch should only return true while the starting platform has not been built yet: ```csharp // If the initial platform is last in the list, only build it again if it has not been built yet if (MPBInitialPlatform == MPBPlatformsList.Last() && MPBBuiltCount < MPBPlatformsList.Count) { return true; } ``` With [Windows, Android] started on Android this gives MPBBuiltCount == 2 on the return trip, so the run falls through to isMPBFinished = true and ReportMPBDone() . If the avatar flow counts differently (it may build the starting platform last and reach this point with a count of Count - 1 ), the same condition keeps that behaviour, but that is unverified. A second option is to make BuildAndUploadMultiPlatform skip the starting platform when it is last in the list and call SetUpNextMPBTarget(cancellationToken, false) , so the count lines up with the existing end check. Local patch used while waiting for an official fix: an early exit at the top of StartMultiPlatformBuild in VRCSdkControlPanelWorldBuilder.cs . When MPB is true, the list has more than one platform, the initial platform is the last in the list and is the active target, and MPBBuiltCount >= MPBPlatformsList.Count , it calls VRCMultiPlatformBuild.ReportMPBDone() , re-enables the UI, shows the "Multi-Platform Upload Finished" notification and returns. This only touches the world builder, so avatar builds are unaffected. Tested: this patch was run in Unity on a real multi-platform publish started from Android, and worked. The run now finishes normally instead of looping. The one-condition change to ShouldContinueMPB above has not been run itself; the tested patch applies the same end-of-run rule from the world builder. Workaround and evidence Workaround without changing the SDK: start the multi-platform publish while the Editor is on Windows, the first platform in the list. The run then goes Windows, Android, back to Windows, and the existing finish check works. After cancelling a looping run, use VRChat SDK > Utilities > Clear Multi Platform Build State, because the state lives in SessionState and survives script reloads. Evidence from the Unity Editor.log of an affected run: A platform switch to Windows was requested ( Requested script compilation because: Switching to platform Windows, Mac, Linux ), followed later by a switch to Android ( Switching to platform Android ). Stack traces in the same log pass through VRCSdkControlPanelWorldBuilder.BuildAndUploadMultiPlatform ( VRCSdkControlPanelWorldBuilder.cs , line 3312), confirming the build and upload ran from the multi-platform path. The log covers a run that the user cancelled, so it shows the switch order but not a final repeat cycle. The repeat was observed directly in the Editor and is described above. Happy to provide the full Editor.log, the Console output, or a screen recording of the loop if useful.

If you set the Type to Parameter and fill up all the fields, even if you change it back to Value it will still keep acting as if it's type Parameter.