Bug Reports

My Experience: We here in Brazil have been forced to use external resources or even endure absurd connection errors that come exclusively from VRChat. I play more than 30 different games and have no connection issues with any of them. Description: However, for over three months now, VRChat has been experiencing an extremely frustrating issue that has even made me stop playing for a few days due to how annoying it is. Randomly, the game disconnects. My friends and I get disconnected in a way where we can still move and walk around the world, but everyone appears frozen. After a few seconds, everything speeds up, and then we can play normally again—until the next disconnect, which can happen anywhere between 1 hour and 2 minutes later. This issue affects people from different regions and with different internet providers. In some cases, only a few players get disconnected while others remain in the world without any issues. When the game fails to reconnect properly, it kicks you from the instance and reconnects automatically. Conclusion: The number of people affected by this issue is not small, and I would really like to see a solution to such a bothersome problem. I love seeing VRChat grow and improve, and I hope this issue gets addressed soon.

This problem occurs when the VRC Camera is launched in an environment where a depth texture has not been issued. In order to use a depth texture in a shader, it must be forcibly issued by a directional light. For this reason, depending on the world, the depth texture may not be issued. To maintain the appearance of the shader's rendering, the display should be switched between the presence and absence of a depth texture, but the depth texture issued by the VRC Camera gets in the way. The VRC Camera calls the depth texture required for certain effects, and it is called even in worlds where a depth texture has not been issued. Plus, the biggest problem is that it shows the depth data from the VRC Camera. A shader that issues a depth texture issued by the VRC Camera will produce unintended rendering results, which can sometimes be unpleasant. Therefore, it is either necessary to prevent the shader from receiving the depth texture issued by the VRC Camera, or to provide another depth texture that the shader can use.

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

Reopening https://feedback.vrchat.com/bug-reports/p/local-players-dont-cast-shadows-caused-by-lights-in-avatars-on-cameras Expected behavior Objects comprising local players cast shadows in cameras similar to a player's view. Actual behavior Objects comprising local players do not cast shadows on cameras. "Cameras" means both photo camera and Camera components in avatars. Description / How to reproduce 1. Open test world I prepared a world for testing culling behavior: https://vrchat.com/home/world/wrld_8d64c603-280f-4dd9-811e-d1db875676ad This world contains spheres for each layers. (see also: https://feedback.vrchat.com/bug-reports/p/culling-mask-for-lights-in-avatars-modified-unexpectedly ) 2. Switch to the test avatar Switch to the test avatar that has a light with shadow. 3. Check casted shadow In the first-person view, the sphere in PlayerLocal layer is casting shadow. In the camera view, the sphere in MirrorReflection layer should cast shadow but actually not. It is tested with world object for easy observation, but meshes in the local avatar behaves similarly. Environment VRChat build 1392

Recent changes to the Pickup Interaction completely break gameplay features in worlds that rely on the player reaching behind their head to grab something. This change has also dramatically reduced the performance of VRCPickup (I saw it add 3ms CPU time to a world with no other changes in it) this is especially apparent while the player is in motion because it makes objects entirely un-selectable until the player comes to a stop. This is destructive to worlds with fast or long-range mid-air action or "Spiderman-style" gameplay features since it severely reduces the performance envelope available for other things in the world, which is completely unacceptable. Please roll this one back.

Open VRChat, Join a world with an Index controller user Have them make a series of hand gestures and see if they are able to properly articulate their fingers individually or if the quest handshapes are shown. I've noticed over the past few weeks, alongside a few other friends, that the hand IK is having some issues when displaying handshapes to other users. It seems to primarily be affecting Index controllers. Locally I will see what I am doing fine, but others report that I am doing a different gesture. I have seen this issue happen with other users as well. An example I have from a Helping Hands class for VRASL: the teacher was showing a sign which I knew was done with another hand shape, but I saw the teacher using a "C" hand, which is the sort of cupped hand shape that Quest controllers usually have. I knew the teacher used Index controllers so I was confused and tried hiding his avatar and showing it, fixing the issue in this instance. Hiding and showing seems to fix the issue in most instances but having to do that every time is a huge hassle, if you can even identify that the bug is occurring. This issue is a big detriment to clarity in communication between people in the sign language community, as it's very difficult to tell if the issue is occurring until you've communicated for a while and realize that what they're saying makes no sense. It is also frustrating for users to have differences between what they're seeing and what others are seeing in general.

Users nameplates in mirror do not correctly reflect the same way you Phyiscally see them compaired to the mirrors copy, The mirror copy follows diffrent Opacity or seems to light a diffrent way compaired to the real nameplate. Apon enabling the world under the mirror layers this issue does disappear, But during raves or partys, The Opacity is still a problem even when in popular worlds. 1: Mirror set to UI+Remote players, no world, Nameplate opacity to 0% (will change) 2: have a friend with their earmuffs on, Tilt the mirror to where you can see both nameplates, Real and mirror variant of it. 3: Play with Opacity slider on the nameplate settings to see effect

Open VRChat Join a queue for a full instance Wait until "queue ready" notification Click "join" through notification or instance in the menu "You are not allowed to travel to that location. Instance queue isn't empty. you must queue first. (Code: 403)" Repeat (I had to retry 7 times on NYE) This issue occurred to me on NYE and a few weeks prior as well. It definitely wasn't a one-off. Associated output log: 2025.01.01 03:25:49 Log - [Behaviour] Destination requested: wrld_64c17705-a5c0-46f5-acae-8760dc13092e:85739~group(grp_887eb49b-153e-41d0-9795-f150b1eebfba)~groupAccessType(plus)~region(eu) 2025.01.01 03:25:49 Error - Failed to join user in instance wrld_64c17705-a5c0-46f5-acae-8760dc13092e:85739~group(grp_887eb49b-153e-41d0-9795-f150b1eebfba)~groupAccessType(plus)~region(eu) - You are not allowed to travel to that location. Instance queue isn't empty‚ you must queue first․ (Code: 403) 2025.01.01 03:25:49 Log - Remove notification from Local notifications:<Notification from username:, sender user id:8JoV9XEdpo to of type: localNotifs, id: 16147921, created at: 01/01/2025 02:25:46 UTC, details: {{}}, type:localNotifs, m seen:False, message: "Press Join to travel."> 2025.01.01 03:25:49 Log - Remove notification from AllTime notifications:<Notification from username:, sender user id:8JoV9XEdpo to of type: localNotifs, id: 16147921, created at: 01/01/2025 02:25:46 UTC, details: {{}}, type:localNotifs, m seen:False, message: "Press Join to travel."> 2025.01.01 03:25:49 Log - Remove notification from Recent notifications:<Notification from username:, sender user id:8JoV9XEdpo to of type: localNotifs, id: 16147921, created at: 01/01/2025 02:25:46 UTC, details: {{}}, type:localNotifs, m seen:False, message: "Press Join to travel.">

While holding the camera in a moving station (The faster the more apparent), some form of camera stuttering begins to occur as if the camera's position lags behind every few frames. Letting go of the camera fixes this issue, but anytime grabbing and holding the camera, it starts again. Worlds with fast moving vehicles such as 'Test Pilots' are the most noticeable locations to see this happen. This issue may have popped up sometime between early October 2024 and late December of 2024. I have only been able to test on PCVR.

An invite to a "private" and a "Invite only" group when viewing on the web states you cannot join but the notification and the ingame notification allow you to join. On the Android app for VRChat the invite function works perfectly fine. (All info unreletated to the report was blurred as its a Private group)