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
Memory leak when destroying objects with UdonSharpBehaviours
While spending time in my (private) world with a bunch of friends, some started crashing, and we noticed that VRC is using huge amounts of RAM. I traced the issue to a script that frequently recreates a UI list, where every entry is an instantiated object with an UdonSharpBehaviour script controlling the UI contents. As it turns out, using Destroy() on an object with an UdonSharpBehaviour does not seem to free the memory - my guess is that the overarching Udon system is still keeping references to every instance of a script that ever existed (for example to run their Update()s?). The memory gets freed shortly after leaving the world, so it's not the end of the world, but i would still appreciate fixing it. As a workaround (and, frankly, just a better/more performant solution) i no longer destroy the entries, but reuse the old ones, and just hide the ones that are not needed, but that doesn't change the fact that it's a bug that other people may be affected by. It may be the reason behind many other unspecified memory leak reports here. I created a world that presents the issue https://vrchat.com/home/world/wrld_edc6dd3e-f111-48c8-a907-7da43a98b9fb Functionally, it just performs Destroy(Instantiate(template)); 100 times per an execution of a FixedUpdate() when the cube/button gets activated (green). The template of the left button is just an empty GameObject, while of the one on the right contains an additional empty UdonSharpBehaviour.
2
·
Bug Reports
·
tracked
Load More
→