Bug Reports

When stretching or squishing a physbone that has angle limits applied, the physbone will still stretch and squish based on the direct distance from your hand to the physbone, even if the physbone cannot move in that direction due to angle limits. This results in physbones that can be stretched downward while being pulled upward, for example. The expected behavior is that physbone stretch and squish are applied with a weight based on the difference between the angle of the physbone and the angle of the direction from the physbone to the hand when the physbone is meeting the angle limit. For example, a physbone with an angle limit of 0, when pulled at a 45º angle to the physbone, should be stretched to sin(45) in degrees. I've attached diagrams for current and expected behavior, The blue is the physbone at rest, green is the stretched physbone, and magenta is the player's hand + distance from the first bone.

I run an event that fills up pretty quickly once we announce that guest doors are open. We open the the instance as a group instance with instance queue enabled. After we get all of the staff into the world for the event, we announce on discord and in group pings that the instance is now open for guests to join. Guests should be joining and starting up a queue at the announced time. What they can currently do is use the "Show Go Button on Load" setting to preload the world and reserve their spot in the instance. We can't tell what guests are doing this because they don't load into the world, we have no idea who hass connected early. They simply join the world with everyone else once the ping has gone out. You can test this easily with 2 other people. 1) Create a group instance with a queue for a world with 2 max slots. Just the two of us works well. 2) Have the instance owner join first and load into the world. 3) Have the person who will use the "Show Go Button on Load" join the instance, but not press the join world button. At this point, the person inside the instance does not see anyone else in the world. The person in the load screen has reserved their spot in the world. 4) Have a third person attempt to join the instance. They will either be placed in queue, or receive an error related to needing to join a queue but it will not place them in a queue. From the perspective of the person inside the instance, no one has joined. The third person cannot join the instance and MAY be able to queue. The second person that is waiting to join can join freely at any time. I do not know how long this instance slot reservation lasts, but it is causing significant issues with group instances with queues.

When Collision Mode was set to "Hit Players" or "Hit Worlds And Players," my own avatar was hit, but other players' avatars were not. When using "Hit World" or specifying "Pickup" in "Hit Custom Layers," the target was hit correctly. Do other players' avatars also need to be running SDK 3.10.3?

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

Once your friend count exceeds 2,000, it takes a very long time to load instances. I’ve been playing VRChat for nearly six years. I look forward to visiting various public instances every day. However, since my friend count increased, I’ve started experiencing a wait time of about 3 to 5 minutes every time I move to a new instance before it loads. I suspect that the system reloads the entire friend list every time the instance list is displayed, so I’d appreciate it if there were a better way to resolve this. Alternatively, I think a feature that allows users to bulk-manage friends they haven’t seen in years or have only met once could help prevent friend counts from growing excessive Translated with DeepL.com (free version)

The Video Player has accumulated quite a few small bugs and inconveniences over time. If technically possible, I would greatly appreciate it if these issues could be addressed. --- Black Flickering Issue with AVPro Player This problem started occurring shortly after the switch to Unity2022. The latest versions of iwaSync and YamaPlayer include their own workarounds, but older versions of iwaSync/YamaPlayer (when using AVPro) as well as players without custom fixes such as TopazChat Player still suffer from black flickering. --- Video Stuttering During RTSP Playback in Specific Conditions Especially in crowded instances on lower-spec PCs, When streaming RTSP at 60fps while VRChat is running at around 20fps, the video becomes noticeably choppy. Although switching the RTSP stream to 30fps currently avoids the issue, many users set OBS to 60fps because the TopazChat Player distribution page states that 60fps minimizes audio delay. --- Request to Move Video Player Processing to a Separate Thread Especially in crowded instances on lower-spec PCs, video playback often freezes for a moment due to various other processes. With RTSP streams, these interruptions cause playback delay to accumulate. The main causes include: Loading process when someone joins or when an avatar is changed Photo capture processing Display/hide toggling when culling is enabled Loading of stage effects on world VRChat's current CPU processing relies heavily on specific thread performance. On modern CPUs, specific thread often maxes out at 100% usage while the remaining threads (including E-cores and CCD1) stay underutilized. Separating the Video Player's processing into its own unrelated thread could potentially resolve these stuttering and lag issues. It may also allow better utilization of currently idle CPU cores.

Avatars start (down)loading on leaving instance. enable Avatar culling join another instance In the Fadeout I see multiple avatars starting to (down)load.

VRChat using absurd amount of RAM, more likely on longer sessions (around 2-4 hours). I haven't played around with it too much to figure out things that could be causing it, but I have noticed that the longer the play session, the more likely it is to happen. Ends up using all of my available RAM, causing freezing and stuttering which can only be solved by restarting VRChat. Does not reset on world/instance rejoin, or going to a new world. I have noticed that RAM usage will be stable, then at some point, it just starts to pile on more and more. ONLY happens on VRChat, every other VR application and non-VR application doesn't do this. Don't know if the results are different on Desktop. This has been happening for a while now and I first started noticing it with the release of the Lunar New Year items update. Maybe could be something that happened there?

1 : Open the VRChat Menu. 2 : Go to the Marketplace/Store tab. 3 : Search for and select the Stellar Conduit portal. 4 : Wait for the 3D preview to load. 5 : Observe the FPS drop. 6 : Exit the store and try to show an avatar.

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