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

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.

An artist named TuxedoPato (Martin, https://x.com/TuxedoPato ) is currently developing a custom locomotion animation set for VRChat. During testing, we encountered a significant issue: the animation behaves differently on the local machine compared to how it appears to remote users. Specifically, the remote version appears unnaturally smoothed, losing much of its intended nuance. We conducted several tests to isolate the problem. Below are key findings and comparisons: Animation complexity directly affects the severity of the issue. Simpler animations show minimal discrepancy, while more intricate ones suffer noticeable degradation. We tested three locomotion sets: - Studio Moca’s Standard Motion for Women ( https://moca-studio.booth.pm/items/5064825 ): Minimal quality loss, likely due to its relatively simple movement. - VRSuya’s Wriggling Locomotion ( https://vrsuya.booth.pm/items/4995578 ): Exhibited moderate degradation, especially in its exaggerated, erratic motions. I also discussed this with the creator, Levin, who confirmed similar concerns. - TuxedoPato’s Custom Animation: Experienced the most severe quality drop. It features numerous subtle movements and a complete overhaul of the locomotion system, making the smoothing effect particularly disruptive. Additionally, we observed that animation fidelity is significantly better in VR mode compared to Desktop mode, where the degradation is much more pronounced. This leads us to suspect that the issue may be tied to VRChat’s polling rate, server tick rate, or network layer behaviour. It appears that locomotion animations are being transmitted over the network rather than executed locally on each client. Despite extensive testing, we were unable to bypass this network behaviour. Several community members echoed our findings, noting that animation data seems to be filtered or compressed during transmission—despite the fact that such data arguably shouldn’t require network mediation at all. At this point, we’ve reached our limit. We’re hoping for insight into whether this behaviour is intentional, a side effect of network optimization, or a bug in how locomotion animations are handled across clients. For testing purposes please check the following avatars that have the locomotion created and setup for your convenience. Full version Locomotion test (walk, run, crouch, crouch run, prone, idle jump, crouch jump, prone jump). https://vrchat.com/home/avatar/avtr_d794808e-6321-400e-b010-8ac9261b9c9f Stripped down version (walk, run, idle jump). https://vrchat.com/home/avatar/avtr_ade7fbe1-707e-4a22-82d5-05e6de7baeac Stripped down version of the locomotion system is downloadable from the link below. This file is stripped down and simplified heavily to narrow down the scope and reduce errors from other factors. https://drive.google.com/file/d/1xRSV3HTQQEBWUAy2_jLnRODdlcQnzM2t/view?usp=sharing Video example between local and remote users. https://youtu.be/86a_RUFllxY

If a physbone is moving into a collider due to sufficient pull or gravity it'll very noticeably jitter. This is an issue with the latest physbone changes. SDK 3.8.1: SDK 3.7.6:

When using the ATOK IME (Input Method Editor) for Japanese input in VRChat, the Easy Anti-Cheat (EAC) system blocks the "ATOK35DE.DLL" file, making it impossible to type in Japanese. This issue occurs consistently and prevents users from communicating in Japanese within the game. Switching to another IME, such as Microsoft IME, may resolve the issue temporarily, but ATOK users face significant inconvenience due to this incompatibility. an IME is software commonly used in non-English speaking regions to input complex characters like kanji, hiragana, or katakana. In Japan, ATOK is a widely used alternative to Microsoft IME. However, EAC appears to misidentify certain DLLs associated with ATOK as potentially harmful or unapproved, leading to this problem. Please investigate whether this is a false positive by EAC and consider allowing ATOK's DLLs to function properly within VRChat. This would enable Japanese users to communicate effectively without switching IMEs or encountering errors. If additional details are needed, feel free to ask!

If a group has a very long name, parts of the UI will overlap on top of it.