World/Udon Bugs & Feature Requests

I would like to request support for passing values directly from uGUI to Udon, by providing public fields or properties in Udon for types commonly used by standard uGUI events. ## Background Currently, passing values from uGUI into Udon is not always straightforward. If the UI is static and predefined, this can be handled by assigning references from Udon to specific uGUI elements in advance. However, problems arise when UI elements need to be created dynamically. In my case, when dealing with such dynamic UI, I end up using workarounds such as: keeping references from uGUI to Udon, which still requires locating the relevant UI element from the Udon side identifying the calling object indirectly via MeshRenderer.probeAnchor (since Transform can be assigned from uGUI events) These approaches are technically possible, but they do not lead to a natural or scalable implementation. They often require indirect patterns or additional setup, especially when working with dynamically instantiated UI. Another possible approach is to attach a separate Udon behaviour to each UI element. However, using Udon components only to pass UI values introduces unnecessary overhead and does not scale well. ## Proposal I propose adding public fields or properties in Udon for types supported by standard uGUI events, such as: string (Input Field) bool (Toggle, ) int (Dropdown) float (Slider, Scrollbar) Vector2 (Scroll View) UnityEngine.Object This would allow a uGUI event to: write a value directly into a Udon behaviour call a CustomEvent let Udon read the value from the assigned input field or property ## Why UnityEngine.Object should be included I would also like UnityEngine.Object to be supported. This would allow a uGUI element to pass a reference to itself, making it much easier for Udon to identify the source of the event. Compared to current indirect methods, this provides a more direct and understandable way to determine which UI element triggered the interaction. ## Example of the intended flow A typical flow would look like this: A uGUI event assigns a value to a Udon behaviour The same event calls SendCustomEvent The Udon behaviour reads the value and handles it Conceptually: using UdonSharp; using UnityEngine; public class UiReceiver : UdonSharpBehaviour { // These are assumed to be provided by Udon itself // public string InputString { get; set; } // public UnityEngine.Object InputObject { get; set; } public void _OnUiTriggered() { Debug.Log(InputString); if (InputObject != null) { Debug.Log(InputObject.name); } } }

I would like to request a single, pre-defined static DataDictionary public field that can be freely used in Udon. (This is not a request to allow users to define arbitrary static fields in U#.) ## Background Currently, Udon (U#) does not allow defining static fields. As a result, sharing state or references across multiple components often requires alternative approaches. At least in my case, when trying to implement a singleton-like pattern, I tend to rely on search-based approaches such as GameObject.Find . This can lead to increased computational cost due to repeated search operations. ## Proposal I propose adding one shared static DataDictionary public field, provided by Udon itself. The idea is: Users do not define static fields themselves Instead, a single shared DataDictionary is provided by the system All Udon/U# scripts can access it By limiting this to a single DataDictionary, it keeps the scope controlled while still enabling many practical use cases. ## Benefits Having a shared DataDictionary would make it easier to: Avoid repeated GameObject.Find calls Share references across systems in a more flexible way ## Expected Behavior The shared DataDictionary is expected to behave as instance-scoped temporary storage: Initialized when joining a world Cleared when leaving the world ## Example Usage Example of registering a reference: using UdonSharp; using UnityEngine; using VRC.SDK3.Data; public class GlobalRegistry : UdonSharpBehaviour { private const string Key = "__global_registry_player_manager__"; private const string ObjectName = "__UdonGlobalRegistry_PlayerManager__"; public static GlobalRegistry Instance { get { if (!UdonSharedData.TryGetValue(Key, out DataToken token)) { GameObject obj = GameObject.Find(ObjectName); if (obj == null) return null; GlobalRegistry instance = obj.GetComponent<GlobalRegistry>(); if (instance == null) return null; UdonSharedData[Key] = instance; } return (GlobalRegistry)token.Reference; } } } Example of retrieving it: using UdonSharp; using UnityEngine; public class SomeSystem : UdonSharpBehaviour { public override void Interact() { GlobalRegistry instance = GlobalRegistry.Instance; if (instance != null) { Debug.Log(instance.name); } } }

A simple few bools that would add IsDesktop, IsPCVR & IsQuest to the VRCPlayerApi class. This would make life a lot better for world creators.

Players and world creators would appreciate a new character controller for VRChat worlds. It should work mostly like VRChat's current character controller, but has a variety of improvements: Players can stand on moving platforms. Going upstairs and slopes is smoother. Players can get pushed around by the colliders. It's better at getting players unstuck from geometry. Udon has greater control over the character controller. ... And more!

Imposters are amazing, but they can clash with many creative and interesting effects world creators can use within VRC. Projectors and camera effects show them as opaque, or invisible. Often times imposters generate impossibly huge, ruining experiences for everyone in the space when their outside bounds are visible. Please give us the freedom to disable them per-world, or even per-instance. Giving this option to world creators would expand creativity, and would not complicate the end-user experience any further. Alternatively, give imposters their own unity layer so they can be rendered separately.

VRChat is working on an improvement to Udon, VRChat's scripting system. Currently, World creators can write code in two different ways: Udon Graph UdonSharp VRChat is introducing a third way: Soba Creators can write Soba scripts in C#, similar to UdonSharp. Soba scripts are compiled to Microsoft's Common Intermediate Language (CIL). This allows Soba to use a variety of features that are not available in the Udon Graph or UdonSharp.

The DataDictionary.GetKeys function allocates a new DataList to contain the list of keys; as this is the only way to iterate a DataDictionary, this forces allocation pressure to occur every time a DataDictionary is iterated. Please provide a way to avoid this allocation - perhaps have an overload where you can pass in a DataList?

I think it would be a nice idea to expose the player's currently set UI colors to Udon, so prefabs and Udon scripts could colorize things like accents, World UIs and even pickups, adding additional personalization that not only effects the players menu, but the world as well. It could also make the user experience more consistent, for example, If the user has a "Light Mode" type color scheme, the UI in things that use this feature would also be light themed. Or if your favorite color is Orange and your scheme uses different shades of orange, A pickup using this feature would change to that color when the user picks it up. Therefore, my point is I think this feature would be a nice and fun addition to Udon that would expand on the VRC+ only feature, and also make the feature more worth a benefit to get VRC+ for more personalization other then the QM/Big Menus.

Currently, PhysBone colliders field have a type of List<VRCPhysBoneColliderBase> . Which is not exposed to Udon. Maybe we can add a field with type of DataList , GetColliders() AddCollider() or other workaround.

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.