Bug Reports

When using Selfie Expression, some avatar jaws will close too much and clip through the mesh. Example avatars: https://vrchat.com/home/avatar/avtr_e11afca0-b6d8-4787-a501-e78739ff742f https://vrchat.com/home/avatar/avtr_1f0e5cad-6a90-401b-b25d-379b2d2bb30e

## Summary When an avatar has a realtime spot light with shadows enabled (culling mask =　Everything), shadow casters other than the local avatar itself are missing from the light's shadow map, but ONLY in the local player's mirror and VRChat camera views. First-person view: world geometry and other players correctly cast shadows onto my avatar My own mirror reflection: their shadows are missing (only my avatar's self-shadow remains) My own VRChat camera: same as mirror Remote clients (other players' views AND their cameras): everything is correct ## Reproduction steps Wear an avatar equipped with a realtime spot light (shadows enabled, culling mask = Everything) set up to illuminate the avatar itself. Join any world that has a mirror. Stand so that a world object (a wall, a pillar) or another player is between the spot light and your avatar. First person: the occluder's shadow falls on your avatar as expected. Look into the mirror, or open the VRChat camera: the occluder's shadow is gone. Your avatar's own self-shadowing still works — notably, a Cube attached to your own avatar still casts its shadow even in the mirror/camera, so only casters outside your own avatar are lost. Another player in the instance sees all shadows correctly, both in their direct view and through their VRChat camera. ## Evidence that this is not a Unity limitation I reproduced VRChat's mirror rendering in the Unity editor (planar reflection camera with a reflected view matrix and an oblique near-plane projection, same technique as VRC mirrors) using the same spot light + Cube setup. In stock Unity, all shadow casters render into the spot light's shadow map correctly, with oblique clipping both on and off. The symptom only occurs in the VRChat client. ## Suspected mechanism The behavior is consistent with the client rewriting the culling masks of avatar lights during the local mirror/camera render passes so that only the local player's own mirror clone remains as a shadow caster — regardless of which player the light belongs to (see related report: "Culling mask for lights in avatars modified unexpectedly"). A light's culling mask determines both what it illuminates AND which objects render into its shadow map. This matches every observation above: in Player A's own mirror, A's clone still casts (shadow visible); in Player B's mirror, only B's clone casts, so A's Cube, world geometry, and other players are silently excluded. ## Related reports "Local players don't cast shadows caused by lights in avatars on cameras" (the complementary case, Tracked since 2024-01) https://feedback.vrchat.com/bug-reports/p/local-players-dont-cast-shadows-caused-by-lights-in-avatars-on-cameras-1 "Culling mask for lights in avatars modified unexpectedly" https://feedback.vrchat.com/bug-reports/p/culling-mask-for-lights-in-avatars-modified-unexpectedly ## Impact Avatar light systems that let the wearer receive shadows from the environment (occlusion by walls, props, other players) work in first person and for every remote viewer, but break in the user's own mirror and camera. This makes them unusable for self-photography and mirror checks, which are core VRChat use cases. --- ## 概要(日本語) 影を有効にしたリアルタイムスポットライト(カリングマスク Everything)を自分のアバターに 載せた場合、自分のアバター以外のシャドウキャスターがライトのシャドウマップから欠落します。 ただし欠落するのは「自分のミラー」と「自分の VRChat カメラ」の描画に限られます。 一人称視点: ワールドジオメトリや他プレイヤーの影は正しく自分のアバターに落ちる 自分のミラー: それらの影が消える(自アバターのセルフシャドウだけ残る) 自分の VRChat カメラ: ミラーと同様 他プレイヤーからはすべて正常: 直接視点も、相手のカメラ越しでも正しく見える ## 再現手順(日本語) 影有効のリアルタイムスポットライト(カリングマスク Everything、アバター自身を照らす向き)を載せたアバターを着用する。 ミラーのある任意のワールドに入り、ワールドオブジェクト(壁・柱)または他プレイヤーがライトと自分のアバターの間に来るように立つ。 一人称: 遮蔽物の影が自分のアバターに正しく落ちる。 ミラーを見る、または VRChat カメラを開く: 遮蔽物の影が消える。自アバターのセルフシャドウは残る — 特に、自分のアバターに取り付けた Cube の影はミラー/カメラでも消えないため、失われるのは「自アバター外のキャスター」だけである。 同インスタンスの他プレイヤーからは、直接視点でもカメラ越しでも、すべての影が正しく見える。 ## Unity の制限ではない根拠(日本語) VRChat のミラー描画をエディタ上で再現し(反射ビュー行列+斜めニアクリップ射影の平面反射カメラ、VRC ミラーと同じ手法)、同じスポットライト+Cube 構成で検証しました。素の Unity では斜めクリップの有無にかかわらず全キャスターが正しくシャドウマップに描画されます。 症状は VRChat クライアント上でのみ発生します。 ## 推定メカニズム(日本語) この挙動は、ローカルのミラー/カメラ描画パス中にクライアントがローカルプレイヤーの アバターライトのカリングマスクを書き換え、シャドウキャスターとしてローカルプレイヤー自身のミラークローンだけを残しているという動作と整合します(関連報告 "Culling mask for lights in avatars modified unexpectedly" 参照)。 ライトのカリングマスクは「何を照らすか」と「何をシャドウマップに描くか」の両方を決めるため、これらのパスでマスクをクローン用レイヤーに絞れば、まさにこの症状になります: 装着者自身のアバター(クローン)はキャスト/受影とも機能し続け、ワールドジオメトリと他プレイヤーは静かに除外されます。リモートクライアント上ではライトは改変されないため、そちらではすべて正常に見えることとも一致します。 ## 影響(日本語) 環境からの影(壁・小物・他プレイヤーによる遮蔽)を着用者が受けられるアバターライト製品は、一人称と全リモート視点では動作する一方、本人のミラーとカメラでは壊れます。 自撮りやミラーチェックという VRChat の中核的な用途で使えなくなります。

Every now and then, late joiners do not receive data for manual synced variables on UdonSharpBehaviours. This can be severly breaking for some worlds! Just imagine a locked private room suddenly being accessible for a late joiner. I found one way to trigger it relatively often: put a few manual synced objects into an otherwise empty world (for example the attached InteractionCounter script). Do a Build & Test, interact with some objects to change and serialize their state Start a second client, the client receives data normally. Don't interact with anything Quit the first client without interacting with anything Start a third client. Often, this one already doesn't get any data on any of the objects. If sync still works, just repeat the process by closing the second client and starting a fourth and so on and try interacting with something again with the client that you are about to close. Or have another regular game client running in the background in a heavy world. For some reason that does seem to have a big influence, too. It is still a bit random, but that way the bug usually happens pretty fast. Note that after it happens, the player can still call RequestSerialization to properly send the data to late joiners, they just don't receive it automatically on join. Also note that it usually affects successive late joiner after it happened once. Also note that doing a RequestSerialization in OnOwnershipTransferred usually avoids that bug. Which is interesting, because it suggests that another RequestSerialization helps even before the new player joins. However, this would only take care of the cases where the actual owner leaves. From observations, I'm almost sure there are more scenarios that can trigger late join sync issues. This issue is similar to: https://feedback.vrchat.com/bug-reports/p/1553-ondeserialization-not-guaranteed-to-fire-for-late-joiners But different in the way that it is not just OnDeserialization not being called: The values of the variables do not change either.

I created a new group and initially assumed this was just a temporary issue, so I waited for a while and refreshed the page several times. Unfortunately, nothing has changed, and I still can't access the General Settings for that group. To make sure it wasn't an issue on my end, I created another test group. The new group works as expected and displays all of the available settings, including the options to edit the group name, description, and other configuration settings. However, the original group that I created still doesn't show any of those options. I can't edit the group name, description, or access any of the General Settings at all. It seems like the issue is only affecting that specific group, while newly created groups are working normally.

In the latest update(s) the Contact Sender when set to "Local Only" doesn't sync globally with a Contact Receiver that is using parameter network sync (Two blendtrees driving a float with a transition going back and forth between the two states using the IsLocal parameter in my case). This method worked fine prior and enabled certain types of interactions while using fewer contacts. (Currently I'm only aware of this affecting PC/Quest/Android but it may affect the other platforms too)

Following up on this completed Canny and developer update from last month , the issue isn't fully resolved. Group members with the "Create Members-Only Group Instances" permission do not see the ability to make group public instances in the VRChat client, but they can still make group public instances and invite themselves by manually crafting a public instance link in the browser. Current mitigation until VRChat resolves the issue: Don't allow group members to open Group instances. Enabling Group+ instance creation does not allow the exploit. The last exploit was left open for over a year. I hope this one won't see the same treatment. I'd really like to allow our group members to create their own group instances without the risk of having unauthorized public instances opened. Thank you to our community member Joakorex for bringing this to our attention. <3

Go to this world https://vrchat.com/home/launch?worldId=wrld_93cb25d9-c3c5-4670-b0fa-c83a730f2c54 Open the Profile menu (or seemingly any menu that scrolls and has text) Scroll until you hit the bottom or top and keep scrolling, helps if you use a joystick. The text elements of the menu bug out, both in live 1867 and beta unity-6 1879.

There has been a major avatar animator desync issue in large instances (60+ players). It seems quite random with who it affects, some players are not desynced (their animations/toggles/facetracking show just fine) and some players are in their default upload state. To reproduce, join a very large instance and you'll notice several players in their default upload state, by asking around or recognizing friends' default avatar. Players that are on the live build 1865, open-beta, and Unity 6 branch can see other players desynced AND they themselves can be affected by the desync.

Hello VRChat team, I’d like to report a critical inconsistency in how group bans are handled when issued through the VRChat website or third-party tools utilizing the API (e.g., VRCX). Observed Behavior When a user is banned from a group via the website or an API-based tool, the ban does not take effect in real-time if the user is currently inside a group instance. Despite being technically banned, the user is: Not removed from the current instance Still able to interact with group members Still enjoying group-related privileges The ban only fully takes effect after the user leaves and attempts to join a new instance, at which point access is correctly denied. Why This Is a Problem This delay has serious implications for moderation: In urgent cases, moderators cannot remove problematic users in real-time. There's currently no mechanism to trigger a forced update or kick based on a group ban alone. It undermines group security, allowing banned users to linger and potentially cause further disruption. This gap in enforcement stands in contrast to other website/API actions such as avatar changes which do propagate instantly in-game. This suggests real-time updates are technically possible, but simply not implemented for group bans. Suggested Improvement To ensure consistent and secure moderation: When a user is group-banned via the website or API, the system should immediately remove (kick) them from any group-owned instance they are currently in. Implementing this would close a loophole in group moderation tools and align the behavior of group bans with the expectations of real-time enforcement. Thank you for your attention. Resolving this would greatly enhance group management capabilities and improve the overall safety of VRChat communities.

I discovered two avatar audio bugs in worlds from Udon that have a gimmick for changing the player's avatar audio. https://creators.vrchat.com/worlds/udon/players/player-audio/#avatar Executing SetAvatarAudioCustomCurve(false) makes the avatar audio for 3D settings for the local player extremely quiet. 3D settings mean that Enable Spatialization is checked for VRCSpatialAudioSource. This occurs regardless of the state of Use Audio Source Volume Curve. Executing SetAvatarAudioCustomCurve(false) for a remote player does not seem to affect the volume. Executing SetAvatarAudioCustomCurve(true) did not affect the volume for the local player, either. Executing SetAvatarAudioForceSpatial(true) makes 2D avatar audio noisy, regardless of whether the player is local or remote. 2D settings mean that Enable Spatialization of VRCSpatialAudioSource is unchecked and Spatial Blend of AudioSource is set to 0 (2D side).