Bug Reports

Using the VRC Avatar Parameter Drive to copy an animated parameter in an animator to a VRC Parameter does not work. Tested copying VRC parameter to another VRC Parameter, and that works. Tested copying an animated parameter to VRC Parameter in Unity editor using gesture manager and that works too. Tested on an otherwise empty avatar without any VRCFury or other addons modifying the upload process. To create a test, follow these instructions: * Create a VRC Parameter component with the following 3 parameters and add to an empty avatar. VRC_Input (Float), VRC_Output (Float), VRC_InRadial (Bool). * Create a VRC Menu component and add two radials. Name one Input, and set parameter to VRC_InRadial, and rotation to VRC_Input. Name the other Output and set rotation to VRC_Output * Create a Unity animator with all 3 VRC parameters as well as a new "Animated Property" float parameter. * Create an animation animating the "Animated Property" from 0 to 1. Have this animation as the only animation in its own layer in the animator, and set the Motion Time to VRC_Input (Thus the Input Radial in our menu will animate the "Animated Property" parameter). * Create another layer with two states, name one "In Radial" and the other "Outside of Radial". * Create a transition from "In Radial" to "Outside of Radial" and set the condition to VRC_InRadial == False. Then create another transition back to "In Radial" with the condition VRC_InRadial == True. * Finally add a VRC Avatar Parameter Driver to the "Outside of Radial" state, set the type to Copy, the Source to Animated Property, and the Destination to VRC_Output. Upload and test. Expected behavior: Adjusting the Input radial will update the animated property, and when exiting the input radial, the animated property is copied onto the Output parameter and thus visible on the output radial menu item. Actual behavior: The VRC_Output parameter is not updated when exiting the Input radial. Adjusting the VRC Avatar Parameter Driver on "Outside of Radial" state to copy from VRC_Input instead of Animated Property, then re-uploading the avatar, shows that copying from VRC parameters works. NOTE: It may appear that the Animated Property is not being adjusted by VRC_Input if you view the Debug Menu ingame. However, creating a third layer with an animation that animates anything visible on the avatar (lets say the scale of a cube or color of a material) and then setting the motion time on that animation to Animated Property proves that the value is still updated. This strange behavior might point to the cause of this bug.

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.

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

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.

This is an ancient bug that was never fixed since 3.0 exist. It was creating small issues but nothing too big. But now I get issues since I have 2 blend tree that fight each other to the death. Write Default On is not affected.

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 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 capturing a print, the preview displays the correct date. However, after printing, the world object version shows an incorrect date. Notably, the file version remains accurate, as demonstrated in the screenshot below. Image was captured and printed at 2024-12-15_03-45-56 CT.

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