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
Manual Udon sync fails despite successful serialization
Manual synchronization stops updating synced variables on non-owner clients with certain field configurations, despite the owner reporting successful serialization. In the failing cases, the non-owner receives OnDeserialization, but the synced fields remain at their initial values. ENVIRONMENT ──────────────────────── Unity: 2022.3.22f1 VRChat Worlds SDK: 3.10.4 Tested with actual VRChat clients in the same instance STEPS TO REPRODUCE ──────────────────────── Attach the provided Float20SyncProbe and Double20SyncProbe scripts to separate GameObjects. Assign a separate TMP text display to each script. Upload the world and join the same instance with two players. The owner assigns new values and calls RequestSerialization() every 10 seconds. Compare the owner's values with the non-owner's values on the displays and in the logs. Both scripts use Manual synchronization. Only the owner writes the synced fields. Neither script uses FieldChangeCallback or calls Networking.SetOwner. Despite their filenames, the attached scripts currently contain: Float20SyncProbe: 27 synced floats. Double20SyncProbe: 14 synced doubles and 1 synced int. EXPECTED RESULT ──────────────────────── The non-owner's synced fields should update to match the owner's serialized values. ACTUAL RESULT ──────────────────────── With the failing configurations, the non-owner's fields remain at their initial values. Reducing the number of synced fields restores normal synchronization. TEST RESULTS ──────────────────────── All configurations below were tested without FieldChangeCallback. 2 doubles : Worked 2 floats : Worked 13 doubles : Worked 26 floats : Worked 14 doubles : Worked 27 floats : Failed 14 doubles + 1 int : Failed 20 doubles : Failed Earlier tests also reproduced the issue with 20 doubles using FieldChangeCallback, while 20 floats worked. Removing FieldChangeCallback did not resolve the double20 failure. The results suggest that the amount or layout of synced data may be involved, but the exact cause is unknown. POSSIBLY RELATED REPORTS ──────────────────────── A single UdonSharpBehavior with VRC Enable Persistence cannot store more than 108 bytes of the same variable type https://feedback.vrchat.com/persistence/p/a-single-udonsharpbehavior-with-vrc-enable-persistence-cannot-store-more-than-10 PlayerObject Persistence Fails to Respect Sync Mode https://feedback.vrchat.com/persistence/p/playerobject-persistence-fails-to-respect-sync-mode Those reports concern Persistence restoration. This issue occurs during ordinary owner-to-non-owner synchronization within the same instance. REPRODUCTION MATERIALS ──────────────────────── The attached scripts reproduce the issue independently and display each client's local synced values, receive count, consistency check, and serialization result.
1
·
Bug Reports
Load More
→