World/Udon Bugs & Feature Requests

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.

The scientific notation for things like CPU frame time in the performance profiler make it almost impossible to quickly read values from it. Please change things like frametime to be represented in milliseconds as normal floats instead of currently nanoseconds in scientific notation

VRChat finally implemented Steam Audio ! And it's a lot easier to hear other players now.🥳 However, Steam Audio can do a lot more! Here's how Valve describes it on their website: > Go Beyond HRTF > Use fully-featured spatial audio attuned to the physical attributes of your in-game geometry. Combine accurate occlusion, reflection, reverb and HRTF effects for natural sounding immersion. The worlds SDK currently does not yet support Steam Audio, so none of the features above are available in VRChat yet. Please implement Steam Audio into the worlds SDK, or allow users to import it into the worlds SDK.

The ability for worlds to have sub-instances to save on performance at the cost of a loading screen. Basically a portal or Udon function pointing to another world ID that creates a child instance, kinda like a linked list. Moving to a child instance should of course have a prompt to avoid world creators using it as a void dimension for people they dislike. (maybe even add a button to return to the parent instance) Rec Room has had a similar feature for a while, it allows for larger worlds without needing to fit everything in one scene. (especially useful for RAM-limited headsets like Quest)

Many worlds have various small textures that could be higher or lower resolution depending on user preference. If users could opt-into having higher/lower resolution textures, then Quest builds could start out smaller (so as to meet the Quest world size limit), and users would have more control over their performance & experience in any given world. Players could also download new textures related to some optional add-on feature in the world. This can somewhat be achieved with image downloading, however that solution doesn't solve this problem for a couple reasons: The 5-second rate limit means you're incentivized to download large atlases for multiple textures, which is something some worlds can't feasibly do. But even if that were always feasible, if hundreds of textures need to be downloaded, the user would have to wait multiple minutes just for the world to initialize. Downloaded images can't be ASTC compressed, so they can't be as small as compressed local textures can be. If I could just upload one bundle of textures at a different resolution than those in the world to begin with, and set compression parameters to have the textures in the bundle compressed to ASTC, then have users download the entire thing at once for Udon to process at runtime, then all of those issues could be avoided. This would also be beneficial for downloaded text, not just images. You could even open this feature up to file types like audio clips or mesh files to give creators even more freedom/potential to create experiences they otherwise wouldn't have been able to before.

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!

Today, the most popular use case of the IVRCImageDownload is to share some picture with friends in VRChat. However, there is one big annoying behavior in IVRCImageDownload for this use case. That's 2048x2048 texture size limit. Therefore, I hope VRChat to have the feature that automatically scale the texture size down to 2048x2048. As described before, it's common to use IVRCImageDownload for sharing pictures with friends. There are several assets specifically designed for this use case such as Image Pad and ImageTablet . However, the 2048x2048 size limit is an annoying for this use case because today picture is likely to exceed this limit. For example, my iPhone 12 mini with default settings will take picture with 4032x3024 pixels and other modern smartphones also take high resolution image by default. In VRChat, I feel it’s common to choose take pictures in QHD, 4K, or 8K but none fits 2048x2048 limit. (FHD and HD fits 2048x2048 though we want to take high-quality pictures.) The texture downloaded with IVRCImageDownload become uncompressed RG, RGB or RGBA texture on the VRAM so It take huge VRAM. Therefore, I think it's reasonable to limit texture size on the VRAM. However, I think it's possible to resize texture down to 2048 off the main thread before loading to to the VRAM. That’s why I request VRChat to have the feature that automatically scale the texture size down to 2048x2048. 日本語要約 IVRCImageDownloadという Image Pad や ImageTablet のような画像を共有するためのアセットで使われている機能に対する要望です。 前述のタブレットではVRChatの制限により2048x2048より大きい画像を指定した場合にはエラーになりますが、エラーにする代わりに 2048x2048 以下に自動的にリサイズするオプションを追加してほしいという要求になります。 (技術的理由により2048x2048より大きい画像をそのまま表示するのは厳しいです) このオプションがあれば、Discordなどに上げた画像を共有するときにエラーが出て使えないという面倒事を減らせるようになります。

Hello VRChat Devs and World Creators, For a better formatted & More In Depth Version of this Feature Request that includes Images and Descriptions of each node, please go to my post on the Dev Forum: https://ask.vrchat.com/t/feature-request-give-udon-u-access-to-instance-information-group-information/27923 Due to the character limits on canny, I cannot put the full post here, Again, Please refer to the dev forum post linked above I propose adding the following Nodes: InstanceInfo IsUserInGroup DoesUserHaveRole GetGroupRules GetGroupDescription GetGroupBanner Now let’s go over some examples for how these nodes will benefit world creators. Determining the Instance Type is super useful as world creators can choose to enable/disable certain features of a world depending on the instance type. For example: In a Public instance I would make sure the permissions system is disabled and all staff objects will be disabled, While in a Group Public instance we would enable all the permission systems and enable staff objects. A notification could appear in front of the player when joining any Group Instance, informing them that they have joined a group instance and Groups can set their own rules. Using the “GetGroupDescription” and “GetGroupRules” Nodes, we can put the rules and description inside the world to make it easier for people to see the rules (cause lets be honest, nobody reads group rules before joining a group public) The “OnInstanceClosed” Event can be used to turn off an open sign at the entrance of a store or bar. The “IsUserInGroup” and “DoesUserHaveRole” Nodes can save world creators and group owners a huge amount of time and hassle, because groups can assign roles to players in the group and have those roles affect what abilities they have within the worlds, eliminating the need for world creators to create super convoluted permission systems for manually assigning roles to players. It can also be useful for things like Patreon/Paid Perks in a world, A lot of people still don’t use/don’t have access to the Creator Economy, or they simply use both. World creators need to set up an external GitHub.io site or a pastebin containing the usernames of paid supporters, and keeping track of people changing usernames and what not is very annoying, Remote string loading also poses the risk of people spoofing URLS to include their name in the list (and yes even though UDON Code Signing has been released, this is still an issue). Being able to access a Main Group for the world and checking if the player has a specific role will eliminate all these issues: * It doesn’t matter if a player changes their username as we won’t be comparing usernames from a list anymore. * Bad actors cannot spoof URLS since we are no longer loading URLS anymore. * Skilled Programmers can set up API applications to automatically add & remove players from roles depending on certain factors (like if they subscribed/unsubscribed) * Since we aren’t relying on external services like GitHub or pastebin anymore, we don’t need to worry about services going down or some people not having Untrusted URLS enabled. This is why I have included the “GroupID” Variable in the GroupAPI nodes, as having access to external groups would make that possible. Quick note: I have thought about people potentially abusing the GroupAPI to spy on players and see what groups they are in, but the amount of time this would take as well as the fact that the player actually has to be IN the world for the GroupAPI to check makes me think that people won’t go through all this trouble. Besides, you can see what groups people are in by simply visiting their profile. If you are really worried about it, you could just make it so if the user has the group hidden from everyone on their profile, it will not show them in the GroupsAPI. GetGroupBanner can be used for automatic decoration of a group instance, like changing a banner above the entrance to the group’s banner. Getting the GroupID of the group hosting an instance is crucial not only for the rest of the nodes but also having verification, What I would do is have a list of group ID’s that correspond to groups I know follow the guidelines set in place by us, and that they follow the VRChat TOS. If the current group ID is on the list then I can show a little “Trusted Group” Icon somewhere to inform new users that they can trust the group.

Greetings, I'd like to have access to the 'ImageConversion.LoadImage' method from Udon : https://docs.unity3d.com/2022.3/Documentation/ScriptReference/ImageConversion.LoadImage.html The reason is : I'm currently making a 3D Model Loading using Udon#, that interprets GLB/VRM data. https://github.com/vr-voyage/vrchat-glb-loader Not having access to LoadImage forces me to re-encode, in advance, the images (PNG/JPEG/WebM) stored in these files into GPU-ready formats (DXT5/BC7/ETC2). ( https://github.com/vr-voyage/glb-textures-converter-rust ) Re-encoding textures in advance leads to issues due to different systems having different requirements (BC7 for PC, DXT5 for Quest, ETC2 for Android/iOS, ...). So while this is not blocking me, being able to use LoadImage would benefit me greatly, since I'd be able to create one asset for all the different platforms, without having to manipulate the data beforehand. This request is similar to https://feedback.vrchat.com/feature-requests/p/udon-expose-unityengineimageconversion-class-and-methods but, I only need 'LoadImage'. I don't need to encode pictures in-game. I'd like to note that using the ImageLoader instead is not possible. The image data is embedded inside binary data. So while there's an URL for the binary data, which is then downloaded using the StringLoader, there's no direct URL to the embedded images. The ImageLoader cannot convert local data (i.e. I cannot pass it a byte[]), it only converts data it can download from a valid URL.

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.