Bug Reports

## 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 の中核的な用途で使えなくなります。

I previously made a post that the camera grid overlay was off by a few pixels but it was since been marked as fixed. However after using the grid I still found that my photos and centering were off by a few pixels so I dug a little deeper. Upon testing, I found that the picture taken within the game and the picture produced was slightly different. This is because the picture taken by the camera actually exceeds what is shown within the camera display by a few pixels. The display is actually cut off unevenly by the black border around the camera. Photo 1 & 2 Shows photo 1 of the camera display and the produced photo 2, the top and bottom of photo 2 exceeds the frame by about a pixel or two even though no space is shown on the camera display in photo 1 Photo 3 & 4 This time I tested the right and left parts of the display and found that the produced photo exceeds the frame on the left side by 3 or so pixels. This is probably also the cause of why using the grid overlay to center the photo does not produce a photo that was completely centered because the display itself is off. Since the grid is probably bonded to the display it is also cut off unevenly by the black border. Thank you for your attention and understanding, if you require any further evidence please a comment below.

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.

I was trying to do the following setup (indicated in the image) to be able to create a pointer to select items in a menu. I noticed that the pointer (in the test case, a contact sender type Box) doesn't calculate the interaction between the cursor and the contact receiver correctly. In my tests, it seems to creates a bonding box around the cursor and calculates based on that, thus showing a proximity that is not consistent with the intersection of the sender with the receiver. This bug affects all currently available versions: public, open beta, Unity-6 and SDK here an an avatar with a example of the bug: https://vrchat.com/home/avatar/avtr_175e72f7-ca81-403b-89be-fa2ad211180c and here the link for a VRCfury prefab with the setup: https://drive.google.com/file/d/1Y-CZVjsg7-ydc9afXYO6-Ee5HmeCoMf4/view?usp=sharing *Note: If you change the cursor type from box to Capsule, the receiver stops working completely, this is also not expected behavior.

## Overview The parameters of a User preset configured on an AudioReverbZone stop being applied correctly starting from the 2nd time (and onward) the user joins the world. The AudioReverbZone itself is active and reverb is applied, but the reverb sounds as if different parameters are being used than the ones originally configured. ## Steps to Reproduce Prepare a world with an AudioReverbZone component that has arbitrary parameters set via a User preset. Join the world (1st time) → Reverb is applied correctly, matching the configured settings. Leave the world once, then join the same world again (2nd time onward). The AudioReverbZone is active and reverb is applied, but the sound is as if different parameters are being used than the ones originally configured. A world for reproducing the above steps has been prepared. https://vrchat.com/home/launch?worldId=wrld_4ced52a1-695c-42c6-9e01-966acc4ea11e An AudioReverbZone and an AudioSource are set up around the green cube in the world mentioned above. When you use the white cube, it will overwrite the parameters of the AudioReverbZone that were set during the world upload. ## Expected Behavior Even after rejoining, reverb should be applied with the parameter values matching the User preset configured on the AudioReverbZone. ## Workaround After joining, if Udon re-overwrites the originally configured parameters, they return to the correct values at that moment. However, if you rejoin after that, the same issue recurs. The issue was not resolved unless the VRChat content cache was cleared. ## 概要 AudioReverbZoneに設定したUserプリセットのパラメータが、ワールドへの2回目以降のJoinから正しく適用されなくなります。 Reverb Zone自体は有効でリバーブはかかっていますが、本来設定した値とは異なるパラメータのリバーブがかかってしまいます。 ## 再現手順 AudioReverbZoneコンポーネントにUserプリセットで任意のパラメータを設定した物を配置したワールドを用意する ワールドにJoinする(1回目)→ 設定通りのリバーブが正常にかかっている 一度ワールドを離れ、再度同じワールドにJoinする(2回目以降) AudioReverbZoneは有効でリバーブはかかっているが、本来設定した値とは異なるパラメータの音になっている 上記の再現手順を実施するためのワールドを用意しました。 https://vrchat.com/home/launch?worldId=wrld_4ced52a1-695c-42c6-9e01-966acc4ea11e 上記ワールドの緑のCube周辺にAudioReverbZoneとAudioSourceが設定されています。 白のCubeをUseすると、ワールドアップロード時に設定してあったAudioReverbZoneのパラメータに上書きします。 ## 期待される動作 Joinし直しても、AudioReverbZoneに設定したUserプリセットの値通りのパラメータでリバーブが適用されること。 ## 回避策 Join後、Udonで元々設定していたパラメータを再度上書きすると、その場では正常な値に戻ります。 しかし、その状態で再度Joinし直すと、同じ症状が再発します。 VRChatのコンテンツキャッシュを削除しない限り、症状は改善しませんでした。

` Cache-WindowsPlayer ` successfully starts using the new cache directory when instructed. ` TextureCache-WindowsPlayer ` however, does not respect this config value and stays onto the user's OS drive.

Since around June 17, 2026, the Visits counts for VRChat worlds may have been increasing abnormally. Based on posts from multiple world creators and external tracking services, this does not appear to be limited to a specific world. Several unrelated worlds seem to have shown a significant change in their Visits increases around the same time. For example, some worlds appear to have roughly doubled their daily Visits increases after around June 17. There have also been reports of unexplained Visits increases in worlds that normally receive very few visitors, worlds intended for small groups or personal use, and newly uploaded worlds where the creator only entered for testing or to take screenshots. At the same time, in some cases there does not appear to be a significant change in Favorites increases, social media promotion, or other factors that would reasonably explain the increase. This makes it difficult to explain the situation as simply an increase in popularity or traffic. Could you please check the following? Whether the Visits aggregation logic or counting conditions changed around June 17, 2026 If there was a change, whether it was an intentional specification change Whether there is currently an issue with how Visits are being counted If possible, whether creators can be informed about any specification changes and their impact Visits are an important metric for world creators when analyzing post-release performance, the impact of updates, promotion results, and comparisons between worlds. If Visits are currently being counted using a different standard than before, it becomes difficult to compare them with past data, which has a significant impact on creator-side analysis. For reports related to this issue, please see my X post below and the quote reposts on that post. https://x.com/oe_tw/status/2070338873633444118

Open VRChat on Meta Quest 2. Join any world. Enable the microphone and speak. Other players hear loud static/screeching instead of my voice. How do I fix it can u help me please?

On my Galaxy S25 Ultra, running Android 16, many images throughout the client (World Pictures, Banner Images at the tops of World Playlists, loading screen tooltip images, etc.) look very wrong (pictures attached). Interestingly, though, the world image that appears on the "Initializing World" screen, looks completely fine. World Images also consistently look extremely noisy on PC (basically like this, just not yellow), but I'd imagine that's a separate issue.

Sit down in VRCStation Use Udon to change VRCStation’s transform Your torso won’t rotate with you and will be dragged along (on desktop, your hands will be too!)