SDK Bug & Feature Requests

I think it's great to add HelpURLAttribute to the all user-facing components on the VRCSDK. There is ? button on the inspector to open help page of each component. This is commonly used in unity-built-in components and recently used by many non-destructive tools such as Modular Avatar , AAO: Avatar Optimizer , lilycal inventory and more. However, because VRCSDK does not add HelpURLAttribute to their components, clicking the ? button will open invalid page like https://docs-redirects.unity.com/script-VRCAvatarDescriptor?version=2022.3 . I think it's better to fix this by fixing link with HelpURLAttribute.

The Harmony package, used by Udon Sharp, and a handful of third-party community plugins for runtime patching in the editor, has been updated to officially support ARM64 on all platforms (Windows, Linux, and yes, Mac). This will correct any in-editor issues when running the Unity Editor on these platforms. Whilst VRChat itself may only support PC & Android, the Unity Editor is a cross-platform utility, and there are a variety of folks with ARM-equipped machines who use such hardware for primary development, and therefor experience issues with the editor without patching. With the advent of full iOS support on the horizon, this may further increase the # of Mac-based content creators. Please update the provided package. Release notes for version where ARM64 support was added Addendum An experimental VPM package can be found at MisutaaAsriel/VRCHarmony which installs a packaged release of Harmony 2.4.1. Unity appears to, in all testing, prefer the package's copy of Harmony over the version included by the VRC Base SDK. This package may also be installed using the following VPM repository: Dreemurrs-Repository VRChat may use the DLL provided from this repository if need be, or take over the package if they so wish. — It is currently built off of the Release target of Harmony, at the solution level, with .NET Framework 4.5.2 using GitHub Actions Note Building Lib.Harmony against the DebugFat target at the project level, or building it for Release against net452 at the solution level creates a successful drop in replacement. The release builds when built at the .NET project level or downloaded from the main Harmony repository currently output a mangled DLL that Unity Burst is incompatible with. A bug report is open on this here: pardeike/Harmony/issues/728 For further reference, the original copy of Harmony is built against .NET 4.5.0, which is no longer a valid target. 4.5.2 was chosen as its nearest replacement. Edited @ EPOCH 1757603286

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.

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

Motivation In Udon Sharp, syntactically, the following is nonsensical: var players = new VRCPlayerApi[VRCPlayerApi.GetPlayerCount()]; VRCPlayerApi.GetPlayers(players); Why doesn't GetPlayers() just… return a preconstructed array of players in the instance already? Why do I need to first create an empty array? In Udon Sharp, at least, one can easy replace or initialize an array with something else like so: int[] arrayOfNumbers; void someFunction() { arrayOfNumbers = someClassInstance.AFunctionThatReturnsAnIntArray() } There is no need to preset the size of the array, as the actual array construction is handled by another function. But in the VRCSDK we are required to pass a prebuilt array to this function??? Make it make sense. Solutions One, Update UDON so GetPlayers() no longer requires passing in an empty VRCPlayerAPI[] sized to the number of players when compiled with a newer SDK; The UDON VM would support both the old and the new behavior. This would have the benefit of, at least in UDON Sharp, being syntactically valid, as the initialized VRCPlayerAPI[] would become effectively an optional variable. If passed, it would follow the current behavior. If not passed, the function will create an array sized to the current number of players currently in the instance automatically. Two, create a separate GetPlayerList() , which would return a VRCPlayerAPI[] of the appropriate size (which could then be stored as a variable), and deprecate GetPlayers(VRCPlayerAPI[] players) in favor of the new function. This would have the benefit of easier backwards compatibility and avoid changing default behavior of an existing function.

I believe it is time to get a solution to the most plaguing issue (in my opinion) of AVPro: Audio Filters I do not think this is a "can't fix" situation. In this proposal I will go over the problem, considerations that have been discussed historically, and the solution I believe is feasible to implement with working sample code. ### Previous Cannys 1) https://feedback.vrchat.com/open-beta/p/986-avpro-player-ignores-lowpass-reverb-and-other-filters 2) https://feedback.vrchat.com/sdk-bug-reports/p/avpro-video-player-audio-filter-issue 3) https://feedback.vrchat.com/sdk-bug-reports/p/sound-effects-are-not-applied-to-audiosource-using-avpro-that-comes-with-sdk3 4) https://feedback.vrchat.com/feature-requests/p/usharpvideo-stream-audio-does-not-support-filters ### Crux of the issue As previously discussed in above canny #1, the current way of handling the AVPro speaker component (type named AudioOutput ) is that the component is implicitly created via AddComponent on the same game object. This has the critical drawback of being unable to respect any audio filters due to the DSP filter chain being _component order dependent_. The second half of this issue is that Unity has no runtime native way to change the ordering of components without fully reconstructing the references. This causes very obvious issues in regards to dependent scene references. (TCL's comment in canny #1 clarifies this as well) ### What has been considered Detecting and destroying/rebuilding known filter components after the implicit component is added. This is bad because all scene references to those components would be lost (eg: UI Events or public Udon variables). To avoid the lost components issue, a full scene search would be required in order to update the references which is costly and fragile. Placeholder components (shims) for each filter type that gets implicitly created after the implicit AudioOutput This is bad because it does not allow users to reference the actual filter components in the inspector (namely an issue for UI Events) Allow adding the AudioOutput script manually in scene and have the speaker search for it before trying to implicitly add the component. This is bad because it requires that the user import the AVProTrial package to be able to use built-in unity audio filters. This needs to be compatible with situations where the user does not wish to import that package so the dependency is decoupled from the feature itself. ### Proposed Solution A shim script that inherits from the AudioOutput class combined with a compiler flag for detecting if AVPro is present, and if not, then have a stub type of the _same namespace and type name_ which is _ONLY_ present in the sdk. Then update the VRCAVProVideoSpeaker to check for the existence of the shim component before creating an implicit AudioOutput, using it instead if found on the game object. This ensures that when the main shim script is loaded in editor, it is already a valid AudioOutput component and the component order is correctly retained so the Audio Filters will work correctly. In the SDK, the script type will check for the existence of AVPro through a version define, and if NOT present, will enable the AudioOutput stub class of the same namespace. An example of what it might be like: https://gist.github.com/techanon/41efc336604e148dde55862bff1778d9 I've tested this specific example in editor and it works there. Can't test in-client obviously.

I'm trying to find the most efficient way to encode long videos for a VRChat world, and I found this table: https://ask.vrchat.com/t/hevc-h265-video-playback/17150 which in theory is exactly what I want, except, the table is two years old, and I have no way of telling whether the information is still correct (I have no Quest hardware to test with, for example). There should be an official table, either in the docs or on the wiki, that states what codecs we should expect to work in each situation (AVPro vs Unity, PC vs Quest).

Issue: The SDK incorrectly throws an error for Mobile incompatible shaders on EditorOnly objects despite those objects being removed on upload due to the EditorOnly tag. These objects being removed on upload still allows the avatar to be uploaded even with the error which may confuse some users. Reproduction Steps: Set up an avatar for uploading to Android with compatible materials Add a mesh to the avatar w/ a PC only shader, such as unity standard Observe that the ""Error"" message in the SDK warning about incorrect shader usage Attempt to upload the avatar, it will fail with the cause being listed as the incorrect shader Change the tag of the new mesh object to EditorOnly Observe that the ""Error"" message is still there despite the mesh no longer contributing to any other performance stats Attempt to upload the avatar, it should succeed as the EditorOnly object is stripped from the avatar before upload Expected Behavior: The expected behavior is that the SDK shouldn't throw an error about materials on EditorOnly objects in the same way as it already correctly removes said objects from the performance stat listings.

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.