World/Udon Bugs & Feature Requests

I would like to request support for efficiently converting byte[] data into Unity struct arrays in Udon, such as: Color[] , Color32[] , Vector2[] , Vector3[] , Vector4[] Ideally, this would be similar in spirit to System.Buffer , but extended to support Unity struct arrays. ## Background Currently, converting raw byte[] data into Unity struct arrays in Udon is not straightforward. While it is technically possible through indirect approaches, these require many Udon steps and become inefficient when handling large datasets. In an actual 3D model loader currently in use, this process may need to handle hundreds of thousands of elements, such as around 300,000 entries. ## Proposal Please add a way for Udon to convert byte[] data into Unity struct arrays, similar in spirit to System.Buffer . For example: Vector3[] vertices = new Vector3[size]; UdonBuffer.TryBlockCopy(byteData, byteIndex, vertices); This would make it possible to directly convert binary data obtained from external sources (such as data fetched from the web) into Unity struct arrays in Udon, without workarounds.

When OSC was added for avatars a long time ago, it was promised to also add it for worlds, but world creators are still waiting for it to be added. Just like with Physbones, this hasn't happened yet and I'm afraid that world creators won't get OSC support because the focus seems to be fully on avatars. Is this still on the roadmap? OSC for worlds / Udon would allow concepts like speeach recognition, tracking world objects / pickups with Steam trackers (e.g. an IRL broom in a world where you can fly on a broom), DMX / light controllers in DJ worlds etc. MIDI is all we have in worlds right now and it's too limited and hard to implement for anything other than a music instrument.

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!

I use an Oculus Quest 3S for my VRChat, and every time I attempt to put in a URL or watch a video it doesn't work. I've tried every method I can think of to fix or solve the issue, but none have worked. If you could please have it fixed for 3S and other VR users like me, that'd be amazing. I want to be able to watch videos on VRChat, but I can't if the video/media player situation remains unfixed. Thanks, have a great day/night

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); } } }

ParticlePhysicsExtensions has various methods for getting particle collision data. Currently these methods are not exposed yet, so we cannot retrieve that data. Examples: https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnParticleCollision.html

I have encountered a problem related to Unity's DSP chain and Udon. I am planning to create an audio focused world, where I need to implement a custom DSP algorithm on audio that can respond to player behavior/controls in real-time. In the native Unity Mono framework, I can insert custom effects into the audio DSP chain by implementing the OnAudioFilterRead method in MonoBehaviour (see https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnAudioFilterRead.html ). In the UdonSharp documentation, I found that there is a method stub for OnAudioFilterRead in Unity events (see https://udonsharp.docs.vrchat.com/events/ ), so I should be able to implement it. However, it does not work in my Unity setup. I also saw a post on Canny mentioning that a component called OnAudioFilterReadProxy should be automatically added to the object if OnAudioFilterRead is implemented (See: https://vrchat.canny.io/udon/p/order-of-onaudiofilterreadproxy ), but this is not happening on my end. Any idea what could be going wrong with my script or configuration? Or it is a bug? My test code is like the following: using UdonSharp; using UnityEngine; using VRC.SDKBase; using VRC.Udon; public class SimpleSineGenerator : UdonSharpBehaviour { [SerializeField, Range(0, 1)] private float amplitude = 0.5f; [SerializeField] private float frequency = 261.62f; private double phase = 0; private double sampleRate = 48000; public void Update() { // verify that the script is running transform.Rotate(Vector3.up, 90f * Time.deltaTime); } public void OnAudioFilterRead(float[] data, int channels) { // DSP code double phaseIncrement = 2 * Mathf.PI * frequency / sampleRate; for (int i = 0; i < data.Length; i += channels) { phase += phaseIncrement; if (phase > 2 * Mathf.PI) { phase -= 2 * Mathf.PI; } float value = amplitude * Mathf.Sin((float)phase); for (int j = 0; j < channels; j++) { data[i + j] = value; } } } }

If you use VRCPlayerApi.SetVoiceDistanceFar() or VRCPlayerApi.SetVoiceDistanceNear() The the value seems to get clamped to a maximum of 10000. I would like the maximum range to be as high as possible for stuff like aircraft radios.

Recently, the number of sophisticated world gimmicks has increased, along with the increasing number of controls and settings. This has forced world creators to design their own UI menus and implement unique methods for accessing them. Especially in large worlds, users need to be able to access the UI menu from anywhere. For example, in VR, they can double-click the trigger, hold down the right stick, or use a gesture. On desktop, they can press the E or Esc keys. These methods can even interfere with the controls of the VRChat client, which has seen an increase in functionality in recent years. For example, pressing up on the right stick causes Vive Wand players to jump. Pressing the E key interferes with camera control. (One reason for this is that Udon cannot receive menu button inputs.) Meanwhile, users often become confused by or even fail to notice the different ways to access UI menus in each world. World creators must always provide guidance on how to access the UI menu. I know that in the past, development of a Udon UI accessible from QM was underway, but that work was suspended. https://ask.vrchat.com/t/developer-update-16-february-2023/16474#p-33374-udon-ui-in-the-quick-menu-14 https://ask.vrchat.com/t/developer-update-16-march-2023/16950#p-34625-update-on-udon-ui-9 https://ask.vrchat.com/t/vrchat-sdk-roadmap-may-2024/24243 From my perspective, a significant factor in this was the amount of time spent supporting smartphone platforms. Smartphone platforms have already been released for both Android and iOS. Now is the time to reboot development of Udon UI! --------------------原文-------------------- 最近、更に高機能なワールドギミックが増えて、その操作や設定も増える傾向にあります。そのため、ワールド作者はUIメニューを独自に設計し、独特な手段で呼び出す実装を強いられています。特に広域なワールドでは、ユーザーはどこからでもUIメニューを召喚できる必要があります。例えば、VRならトリガーをダブルクリックであったり、右スティックを下に長押ししたり、あるいはジェスチャーをしたり…デスクトップならEキーを押したりEscキーを押したり… これらは、近年機能の増えたVRChatクライアントの操作と干渉することさえあります。例えば、右スティックの上入力ではVive Wandのプレイヤーはジャンプしてしまいます。Eキーではカメラを操作しようとする時に干渉します。(理由の一端に、メニューボタン入力を Udon から取得できないのもあります) 一方でユーザーは、ワールドごとに呼び出し方の違うUIメニューに戸惑い、あるいは気付かない事もしばしば起こっています。ワールド作者は、常にUIメニューの呼び出し方を案内する必要があります。 私は、過去にQMからアクセスできるUdon UIを開発していて、しかし中断している事を知っています。 私の認識では、スマートフォンプラットフォームの対応に工数が取られていた事も重要な一因です。既にスマートフォンプラットフォームはAndroid, iOS共にリリースされています。今こそUdon UIの開発をリブートする時です！

gets if local player is has moderation perms (ie: world creator, instance creator, group moderator). I want my moderator room to available to members of any group that visits my world, as opposed to a static whitelist which unfairly favors my group's moderators (for clarification: by "moderator room" I mean "a small private meeting room used by moderators to have private conversations without having to leave the instance")