Bug Reports

The number of animation layers heavily affects performance due to unnecessary inverse kinematic calculations. Even blank animation layers with zero weight in the FX layer can trigger this behavior. The offender is seen in the profiler as Animators.IKAndTwistBoneJob. It runs as many times as the currently loaded animation controller with the largest number of layers. Although the individual run time is small, they very quickly add up. Slower CPUs seem to be more adversely affected by this. The time taken by these extraneous calculations quickly grows larger than all normal animator activity. This behavior only happens on animators that have a unity avatar/armature. When that is removed, this behavior goes away and the number of layers ceases to be a significant cause of lag. Most FX layers do not have any interaction with the armature, so it is likely that this behavior can be fixed for almost all FX layers. However from debugging the unity editor in visual studio, it appears the this happens in a native unity function named Animator::UpdateAvatars. It is likely that in most if not all cases, these calculations are completely wasted on FX layers and provide no benefit at all while consuming significant amounts of main thread time. Somehow these calculations need to be only run for layers that require them. Additionally providing a way to get parameters in sub animators would allow logic to be moved out of the main animator completely sidestepping this problem. They would not have a unity avatar associated with them, so this problem would not occur. It would also allow completely disabling animators when not in use. Please attempt to find a way to prevent this behavior or consider convincing your Unity contacts to implement a fix. This seems to be one of the largest contributors to animator lag. I have a full write-up with more profiler images and further explanations. https://docs.google.com/document/d/1SpG7O30O0Cb5tQCEgRro8BixO0lRkrlV2o9Cbq-rzJU

In my world with multiple decks of cards (each deck being multiple objects, each with their own VRCObjectSync), after players grab cards, move them around, etc. some late joiners will sometimes join to see ALL the cards in their initial positions (rather than where they should be after moving), but rotated properly.

Issue: When a world has been updated to a state that makes it incompatible with older versions and you try to join an instance that is running an older version you will be given a Network Incompatibility warning and can't join said instance. This is expected behaviour according to the documentation . There appears to however be an issue with the "sending the player home" flow, as currently you will just end up sitting in a black void after having received the warning message. This can only be resolved by restarting your client. Expected Behaviour When trying to join a world that is incompatible the player should receive the warning and be send to their home world like it is described in the documentation.

Video players in VRChat are failing to play YouTube web,web_safari 1080p formats and are falling back to android_vr extractor for a premuxed 360p format ( -f 18 ). This is because yt-dlp 2026.03.03 has a broken web,web_safari extractor which returns The page needs to be reloaded. errors. As a result, the video quality of YouTube videos in VRChat is worse than usual (360p). Expected behavior: 1080p web_safari formats (M3U8), 1080p YouTube video playback in VRChat video players. (IIRC, a M3U8 playlist format is playable in VRChat.) Fallback to 360p android_vr formats in VRChat for YouTube playback in case web_safari breaks in the future. Actual behavior: 1080p web,web_safari unavailable, fallback to 360p android_vr formats in VRChat for YouTube playback. Test URL: https://www.youtube.com/watch?v=kEAC8eeQWcg (A soothing AI reads stories to you in Thad Tiny Library by Thad Gyther) Diagnosis: https://ask.vrchat.com/t/avpro-player-vizvid-plays-low-resolution-yt-videos/48357/4 Bug resolution: Update VRChat's yt-dlp fork to the latest stable yt-dlp release, in this scenario 2026.03.17 (yt-dlp-ejs 0.8.0). 1080p web_safari M3U8 formats are available there. Steps to reproduce: PS C:\Users\linda.LINDALAP\AppData\LocalLow\VRChat\VRChat\Tools> .\yt-dlp.exe --version 2026.03.03 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.03> .\yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -F https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] Extracting URL: https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] kEAC8eeQWcg: Downloading webpage [youtube] kEAC8eeQWcg: Downloading web safari player API JSON ERROR: [youtube] kEAC8eeQWcg: The page needs to be reloaded.. The page needs to be reloaded. Deno version 2.7.13 is installed for JS player formats with winget install DenoLand.Deno for testing. Upstream yt-dlp 2026.03.17 used for testing from: https://github.com/yt-dlp/yt-dlp/releases/tag/2026.03.17 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.17> .\yt-dlp.exe --version 2026.03.17 PS C:\Users\linda.LINDALAP\AppData\Local\Temp\yt-dlp_upstream_2026.03.17> .\yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -F https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] Extracting URL: https://www.youtube.com/watch?v=kEAC8eeQWcg [youtube] kEAC8eeQWcg: Downloading webpage [youtube] kEAC8eeQWcg: Downloading player 8456c9de-main [youtube] [jsc:deno] Solving JS challenges using deno [youtube] kEAC8eeQWcg: Downloading m3u8 information [info] Available formats for kEAC8eeQWcg: ID EXT RESOLUTION FPS CH │ FILESIZE TBR PROTO │ VCODEC ACODEC ASR MORE INFO ────────────────────────────────────────────────────────────────────────────────────────── sb3 mhtml 48x27 2 │ mhtml │ images storyboard sb2 mhtml 80x45 1 │ mhtml │ images storyboard sb1 mhtml 160x90 1 │ mhtml │ images storyboard sb0 mhtml 320x180 1 │ mhtml │ images storyboard 91 mp4 256x144 30 │ ~ 1.21MiB 170k m3u8 │ avc1.4D400C mp4a.40.5 93 mp4 640x360 30 │ ~ 4.98MiB 696k m3u8 │ avc1.4D401E mp4a.40.2 18 mp4 640x360 30 2 │ ≈ 3.64MiB 510k https │ avc1.42001E mp4a.40.2 44k 360p 300 mp4 1280x720 60 │ ~25.50MiB 3566k m3u8 │ avc1.640020 mp4a.40.2 301 mp4 1920x1080 60 │ ~39.47MiB 5518k m3u8 │ avc1.64002A mp4a.40.2 Fixes: https://feedback.vrchat.com/feature-requests/p/update-to-yt-dlp-20260313-yt-dlp-ejs-070-to-improve-youtube-playback-compatibili Screenshots: 360p in VRChat (world: Coze Isle by Shinyflvres), 1080p in YouTube web browser.

The VRC+ banner in the Quick Menu where you go to gift drop from the Here tab floats way too far above the menu.

this banner leads to VRC+ Tab, instead of the content.

Inflatable Swimmies are shown as an item in the bundle UI when they are actually an accessory

When the in-game sliders for adjusting Look-At-Me Offset are used VRChat sends either the new value for the Horizontal Offset with the address /usercamera/LookAtMeYOffset or the new value for the Vertical Offset with the address /usercamera/LookAtMeXOffset over OSC (whichever has changed), but when VRChat receives a float over OSC on address /usercamera/LookAtMeYOffset it changes the Vertical offset and then loops back the float sent on both /usercamera/LookAtMeYOffset and /usercamera/LookAtMeXOffset. The same also occurs when VRChat receives a float over OSC on address /usercamera/LookAtMeXOffset, it changes the Horizontal offset and then loops back the float sent on both addresses.

As the title says. The preview of the loading screen "Tropical Breeze" in the shop causes a low framerate (for me it drops around 15-25 fps), and the visuals look overexposed (my eyes!).

If you go to the store page for the Tropical Breeze Loading Screen and then view details after letting the store page preview load, the music for the loading screen will play twice on top of each other. https://drive.google.com/file/d/1ZjDrvx6ckVYPik1ZHoSoFv1pKHbDvkKx/view?usp=sharing