SDK Bug & Feature Requests

The last SDK version I was able to successfully test was 3.8.1. This one allows for lighting to bake successfully On latest SDK 3.8.2 (And 3.8.2-beta.1): 'Generate Lighting' with unity built in lighting menu -> Background task stuck "Waiting for shaders to compile" - The time to completion continuously rises and never moves past 5% I am using an AMD rx 5700xt, screenshot attached is from another user who has the same issue and is using NVidia.

Summary: The VRChat SDK is causing Unity to falsely detect prefab overrides when no actual changes have been made. This issue occurs both during general SDK activity (not just when opening the SDK tab) and specifically when uploading or updating avatars. It often flags the Avatar Descriptor component as "changed," even when untouched. Steps to Reproduce: Open a Unity project with VRChat SDK (SDK3 - Avatars). Create or load a prefab-based avatar. Upload or re-upload the avatar via the SDK. After upload completes, observe that the avatar prefab now shows "Unapplied Overrides" in the inspector. Open the prefab and inspect the VRC_AvatarDescriptor — Unity claims it's been modified, even though no changes were made. Expected Behavior: Uploading or interacting with the SDK should not trigger false prefab overrides when no values were changed. Avatar Descriptor and other components should remain untouched unless explicitly edited. Actual Behavior: Prefab instances are flagged with "Unapplied Overrides" after uploading or interacting with the SDK. The VRC_AvatarDescriptor component is frequently shown as modified, despite no visible differences. These overrides appear without user input, leading to confusion and unnecessary prefab management. Known Triggers: Uploading or re-uploading avatars. SDK interactions during project use (not limited to opening the SDK tab). SDK updates that introduce new systems like (often re-introduce the bug): PhysBones, Constraints, Per-platform Avatar Overrides Impact: Disrupts normal Unity workflow and prefab integrity. Forces creators to manually check or apply overrides to maintain consistency. (Sometimes not even working and getting stuck in an override change loop) Risk of unintentionally applying unwanted changes or overwriting important prefab data. Time-consuming and frustrating for creators managing large or complex prefabs. Additional Notes: This issue has persisted across multiple SDK updates and is easily reproducible. It appears tied to how the SDK modifies or refreshes component data internally. Given how fundamental prefabs are to Unity projects, this issue should be considered a high-priority bug — especially for avatar creators relying on clean and reliable prefab behavior.

Problem Opening VRCSDK Builder page or changing the selected avatar will revert pose (transform) to rest pose defined in the 'Avatar' asset of the root Animator component. Cause of the problem In the OnGUIAvatarCheck method of the VRCSdkControlPanelAvatarBuilder class, it will call Animator.Rebind method to check the situations you call "nested armature". However, Animator.Rebind function will write the default pose defined in the 'Avatar' asset so it will revert any pose changes made in the editor. This is annoying since this will disturb creating animation clips and testing them in the editor. Solution One solution is to use Animator.Rebind(bool writeDefaultPose) private method and pass false to writeDefaultPose parameter, instead of passing true to it, which is the default value. This method is not available as public API but it will keep available until Unity 6000.2.0b4 (the latest available C# reference version . Another solution is to collect the current pose before calling Animator.Rebind and restore it after the call but this takes more code.

I found an issue where the value from InputUse switches back to false while holding the right trigger on a controller (PS3 controller with DsHidMini). The input from "Oculus_CrossPlatform_SecondaryIndexTrigger" for example is always correct. This does not happen in game, only in ClientSim. Here is a video of the issue: https://streamable.com/dqypwr

An Error or Warning should be shown in the SDK build window when a spawn transform is found to be at or below the respawn height y value. This can be done on accident and isn't something that would be obvious to end users (even with the new respawn plane handle). Especially since it causes the Quick Menu to close, meaning you practically soft lock the client if all respawn transforms are underneath the respawn height. I imagine quite a few creators would not be able to make the connection that their player being locked with no access to the Quick Menu means they are being respawned constantly.

In an avatars scene if you enable & use a camera to upload a new avatar thumbnail, select a different GameObject, then disable the camera, and save the scene, Unity will crash. Likely related canny Scene setup: Add a camera to your scene to use for the camera Disable the camera by default (Unsure if required?) Save scene. Repro: Enable the camera Gameobject Upload a new thumbnail for an avatar in this scene using it Select GameObject other than the camera (??) Disable camera GameObject Save scene Video: https://www.youtube.com/watch?v=v-_O6c-W28E

This new version seems really emjoy hanging in Scheduler.Tick. Maybe I got too many avatars?

VRC Object Sync by default is a continuously operating script that pings locations to all players even when objects are at rest or behind the player/occluded by the world. As a result, once the object pool reaches higher numbers, over 200, frame times are permanently hindered as the game waits for all these pings. I'd tested in my world the difference between VRChat's default Object Sync script and MMMaellon's Smart Object Sync on about 212 objects. Performance with default object sync raised frame times to 16.7-17ms. MMMAellon's Smart Object Sync brought framerates down to 2.4-3ms, an overall savings of around 4-5x performance improvement. And this is not on a slow PC - this is on a Ryzen 7 7800x3D with a Noctua NH-12s cooler, an RTX 4070, and 64 GB of RAM. You cannot simply add power to fix the problem. MMMaellon's script does a lot to improve performance, but the core function allows objects at rest to stop pinging unless exerted by an external force. They are also developing a newer version of the script that cuts bandwidth in half. As VRC adds more dynamic global objects through the inventory system, I fear this issue will only become more exasperated the longer global sync gets ignored. I highly recommend enabling higher performance syncing methods by default for newer worlds and enabling the older sync system only when absolutely necessary. As many maps feature QV pens, pool tables, grabbable pillows, coffee and drink prefabs, and other grabbable synced objects, this will have an immediate performance impact across the entire game, and it's something all creators need to be made aware. https://github.com/MMMaellon/SmartObjectSync

UdonSharp reports Utilities.ShuffleArray (the T type) as not exposed to Udon, despite it working just fine in an UdonGraph program. The int[] version of this function does compile in UdonSharp.

For some reason, RuntimeLogWatcher from UdonSharp loads entire log files of VRChat in memory and scans it, every editor tick. If for some reason, there is a large log file of VRChat (for example because some world spams with messages), then right after Unity starts, RuntimeLogWatcher can't handle it gracefully and just explodes in UI hangs and RAM usage. Before Unity loads in usable state, it is already have less than 1fps and uses dozens gigs of ram. For some reason is also cannot be turned off: even if Output watch mode is set to Disabled, it is still there.