Bug Reports

I am reporting that the issue described in the previous Canny post steam-audio-open-beta#1662 has not been sufficiently resolved. ( https://feedback.vrchat.com/steam-audio-open-beta/p/1662-steam-audio-beta-audio-sources-close-to-head-not-panned-hard-enough ) Specifically, the panning and spatialization of audio sources located in very close proximity to the head remain too weak. The separation between the left and right channels is not distinct enough when the source is near the ear. This lack of accurate spatialization critically impacts immersion, particularly for ASMR content or intimate social interactions where close-range audio positioning is essential. Below is a comparison demonstrating that the issue persists in the current build compared to earlier versions. Reference Videos: Live Build (2025-03-04) - Reference: https://youtu.be/8UoSqduh9Y0 Live Build (2025-12-07) - Current Behavior: https://youtu.be/j3RVQOdXbNo

When using VRChat's native hand tracking on PCVR, the hand movements that are displayed locally do not correspond accurately to what remote users see. The core issue appears to be that finger curl data is transmitted on a per-finger basis rather than per-joint, similar to the legacy Index-controller finger curl implementation. This leads to incorrect representation of specific hand signs, particularly those that involve fingers being straight but angled. Users employing custom OSC hand tracking do not face this problem, highlighting a discrepancy in how hand tracking data is processed and transmitted in VRChat. Steps to Reproduce: Use VRChat on PCVR with native hand tracking enabled. Perform hand signs that require specific joint-based finger curls (e.g., fingers that are straight but angled). Have a remote user observe the hand signs. Compare the hand movements observed by the remote user with what is displayed locally. Observed Result: Remote users observe incorrect or misaligned hand movements due to finger curl data being transmitted per-finger instead of per-joint. This issue is consistent across different users and instances, regardless of whether VRChat is restarted or even reinstalled. Expected Result: Hand tracking data should be transmitted per-joint rather than per-finger, ensuring that remote users see an accurate representation of the local user’s hand movements. This is essential for the proper execution of Sign Language and other precise hand gestures in VRChat. Frequency: Always Impact: This bug severely impacts users who rely on Sign Language for communication, as it prevents accurate representation of certain hand signs. The lack of precise hand tracking translation compromises the ability to communicate effectively using Sign Language in VRChat. Additional Information: The issue occurs across multiple users, instances, and devices. Users with custom OSC hand tracking do not encounter this issue, suggesting a difference in how tracking data is handled. Accurate transmission of hand movements, down to the individual joint level, is critical for Sign Language and other detailed gestures.

I thought i was going insane for the longest time but after checking thinking that my centering was off but I realized it wasn't my fault in the end. The grid itself is off. (Attached file for middle section compared to top and bottom) (Middle row is shorter than top row by 3 pixels) (Middle row is same size with bottom row) (Right column is wider than Left column by 5 pixels) (Left column is wider than Middle column by 1 pixel) Also the overlay is clipping into the dark outer border of the camera by about one pixel.

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

After the latest avatar SDK update, the root of the avatar jitters in 3-point tracking. This is affecting all the objects outside the humanoid armature. The jitter goes away if the avatar goes to the crouch mode, or if "Use Auto-Footsteps for 3 and 4 point tracking" is disabled in the VRC Avatar Descriptor. I tried to capture the behaviour using a fresh unity project (created with VCC) and the default pilot avatar, with a cube in the root as a place holder. https://drive.google.com/file/d/14VpjrsixiTsqfLtDAZFJlDIM4FOj7ZBf/view?usp=sharing

World owners for some reason can be kicked from their worlds by whoever the instance owner is.

I've known about the problem with the index finger bending on its own for a long time, around 3 or 4 years. I believed the VRChat team would fix it, but they never did. I need to report this bug, which affects people using Valve Index controllers. For years, we thought our controllers were broken, leading us to replace them through SteamVR or buy new ones, but the issue is actually a bug in VRChat. For those of us who are deaf and use sign language, this bug is particularly uncomfortable and causes miscommunication sometime. https://youtu.be/aQ_PQnsJqqs

In larger events, its not uncommon for people to pull out something like the bubbler and start using that during certain times. Currently it seems there's no limit on the number of new, global audio sources spawned by this (i.e. 80 people with bubblers == 80 new audio sources, minimum 160 audio sources on top of avatar audio & world audio). This causes audio issues like stuttering, albeit I'm unclear if its VRChat, Unity, or AVPro at cause (hard to reproduce, sorry!). A specific failure case is a large music event with 80 people in a small area, lots of people pull out bubblers, and then the music stream stutters due to this. This issue was immediately resolved by disabling items As a practical matter (and also looking to the future) nobody would ever want to hear this many item audio sources at once. Its overwhelming & provides little value after say 5x of the same type, and is likely to cause audio issues if unchecked. Additionally, although a moot point if the above is addressed, setting Items volume to 0 I suspect does exactly that and lowers the audio sources volume to 0, which does not _disable_ them from Unity's perspective. For all audio source sliders, disabling the audio sources entirely would be safer if volume == 0

The custom laser & menu colors persist when logging out from an account with VRC+ customizations and even when logging into another account that doesn't have VRC+. Image shows what happened after forcibly being logged out from multiple connection errors (only laser color persisted). Log into an account with VRC+ Apply custom UI theme Logout of the account (Optional) Log into a different account without VRC+

Emoji shared from other users show up as white squares in the expressions menu and the inventory menu, unless you click them individually to view them in the inventory, making it extremely difficult to keep track of which emoji's are which until you use them.