World/Udon Bugs & Feature Requests

Post about current World or Udon bugs feature requests. One item per post!
Non-constructive and off-topic posts will be moved or deleted.
Expose Graphics.SetRandomWriteTarget
Note: This request is an excerpt of this document which contains some additional context and suggestions for a implementation. With the introduction of VRCGraphics.Blit and asynchronous readback feature, we are closer than ever before to having compute-shader-like capabilities in VRChat. However, we are still missing a critical component: Random writes! Random writes are the ability to write to any location in a block of memory, represented as an unordered access view (UAV) - in our case, these UAVs concretely are just RenderTextures. Random writes are hugely useful for making compute-shader-like code performant, and for many of the things that people tend to use real compute shaders for, they are downright required. This is due in part to the fact that they enable the use of atomic operations (example), which open up the doors to a bunch of algorithms that are infeasible or very tricky to implement without. We could get very close to approximating compute shaders today with the addition of one single piece of API: Graphics.SetRandomWriteTarget . With this API, you can do random writes in fragment shaders, which brings them much closer to compute shaders (see the initial link for example code). Here are some examples of possible use cases: Persistent data storage in a shader without jank. No need for GrabPass abuse, Custom Render Textures, or Camera loops. Just bind a RenderTexture and you are good to go. Communication between shaders without jank. Simply bind your render texture, and any fragment shader can now access it with both read and write access. Custom realtime GI systems. I implemented a system that places and integrates light probes dynamically based on camera depth using this piece of API. Better fluid simulations. In general, pretty much any kind of shader-based simulation can benefit from this. Either by being made simpler to implement, faster, or becoming feasible in the first place. Potentially speedup for AudioLink's DFT algorithm? Fast reduce-style operations such as summing or maxing over a domain. GPU based sorting.
2
·
Feature Requests
NavMesh Link traversal fails in VRChat after the October 2026 update
NavMeshAgent-controlled NPCs are unable to traverse NavMesh Links in the live VRChat client. The NPCs approach the beginning of the link, walk in place for a while, and eventually abandon their movement. The issue occurs even with a single NPC, so it does not appear to be caused by crowd avoidance. The same behavior was observed with the legacy OffMeshLink component. The issue has also been reported by another user following the October 2026 VRChat update. Environment Unity Editor: 2022.3.22f1 VRChat Worlds SDK: Updated to the latest available version ClientSim: Works correctly Live VRChat client: Traversal fails Steps to Reproduce Create two NavMesh surfaces at different heights. Connect them using a NavMesh Link. Configure a NavMeshAgent to move between the surfaces. Test in ClientSim: The NPC traverses the link successfully. Upload the world and test in VRChat: The NPC gets stuck at the beginning of the link. Expected Behavior NavMeshAgents should traverse NavMesh Links in the live VRChat client, as they do in ClientSim. Actual Behavior NavMeshAgents get stuck at the link entrance, walking in place without traversing it. Additional Information I have tried adjusting the link positions and width, enabling Auto Traverse Off Mesh Link, and updating the Worlds SDK, but the issue persists. Since the same issue occurs with both the legacy OffMeshLink and the newer NavMesh Link, this may be related to changes in the VRChat runtime following the Unity 6 migration. I would appreciate it if this could be investigated.
0
·
Bug Reports
Load More
→