SDK Bug & Feature Requests

SDK 3.8.2 Currently all test avatars are shown below uploaded avatars, which could be a long list depending on how many avatars are uploaded. Moving test avatars to the top will make it easier to manage test avatars.

I want API to run avatar validation of SDK and get list of errors / warnings of specific Avatar/GameObject. In the NDMF , a framework for non-destructive tools, there's feature to run non-destructive tools and see if tools raise errors (called test build). I think it's good to show errors from VRCSDK on the test build, but there's no API to run and get list of validation errors so its hard to show errors without sdk api. Therefore, I'm requesting for API. It would be great if this API is provided as a static method of some class and does not require opening control panel since control panel might not be opened on test building avatar.

In the new SDK 3.7.6, it's now possible to build a world on Linux, but it is not possible to launch a local test with proton. Pls add proton support, similarly to: https://github.com/BefuddledLabs/LinuxVRChatSDKPatch

VRC Object Sync by default is a continuously operating script that pings locations to all players even when objects are at rest or behind the player/occluded by the world. As a result, once the object pool reaches higher numbers, over 200, frame times are permanently hindered as the game waits for all these pings. I'd tested in my world the difference between VRChat's default Object Sync script and MMMaellon's Smart Object Sync on about 212 objects. Performance with default object sync raised frame times to 16.7-17ms. MMMAellon's Smart Object Sync brought framerates down to 2.4-3ms, an overall savings of around 4-5x performance improvement. And this is not on a slow PC - this is on a Ryzen 7 7800x3D with a Noctua NH-12s cooler, an RTX 4070, and 64 GB of RAM. You cannot simply add power to fix the problem. MMMaellon's script does a lot to improve performance, but the core function allows objects at rest to stop pinging unless exerted by an external force. They are also developing a newer version of the script that cuts bandwidth in half. As VRC adds more dynamic global objects through the inventory system, I fear this issue will only become more exasperated the longer global sync gets ignored. I highly recommend enabling higher performance syncing methods by default for newer worlds and enabling the older sync system only when absolutely necessary. As many maps feature QV pens, pool tables, grabbable pillows, coffee and drink prefabs, and other grabbable synced objects, this will have an immediate performance impact across the entire game, and it's something all creators need to be made aware. https://github.com/MMMaellon/SmartObjectSync

Currently, upon reviewing the request headers, there does not seem to be any way to differentiate between string and image loading requests for the same URL. With the limitations of VRCUrl, it would be very nice to have a way to tell them apart. Some potential solutions include specifying a value for the Accept header, extending the User-Agent header, or adding a new VRChat-specific header. I believe the last option would be the least likely to break any existing worlds, but there are various pros and cons of each. An example use-case would be a system to download a mesh (binary data, string loading) and its texture (image loading) using a single URL. The server could use the headers to determine which content it should respond with. This would also be useful for decreasing the size of VRCUrl pools as used in YTS and other worlds. We are already using useragent-dependent responses between video player and string loading useragents, but we'd like to do the same with image loading too.

In VRCSDK3 Avatars, if BlendShapeNormals in FBX is Calculate, the validation is displayed. If I press AutoFix here, LegacyBlendShapeNormals will be enabled. But I think LegacyBlendShapeNormals is an old method as it is named Legacy. Since relying on AutoFix in VRCSDK is not a way to get out of the old method, we would like to change it to use the new method. Instead of enabling LegacyBlendShapeNormals, I would like to change BlendShapeNormals to None. Incidentally, depending on the new Blender FBX export settings, LegacyBlendShapeNormals may break mesh normals. So I am trying to find a way to avoid using LegacyBlendShapeNormals. I am using VRCSDK3Avatars 3.6.0. Thanks.

I would love to see the size limit increased for Quest atleast up to 15MB or 20MB The 10MB limit is killing the creation process for Quest and has been giving me issues causing me to make my avatars look like pixelated garble for questies. What's the point in creating avatars when you're forced to make avatars look like garble. Personally, I would say drop Quest 2 support or increase the size as it's a pain to deal with the 10MB limit. SDK Version 3.7.4

Within a render callback such as OnWillRenderObject, it's useful to be able to check which camera is rendering. Unity has "Camera.current" for this, but it's not exposed to Udon. The new camera API is awesome, but without a property like that, I still can't make my UdonPortals prefab render correctly in the hand-held camera because there's no way to tell which camera is currently triggering OnWillRenderObject. I'd like a property to tell which camera is responsible for the render. A really simple implementation would be a new read-only property like: VRCCameraSettings.CurrentCameraType: An enum consisting of the values "ScreenCamera" or "PhotoCamera". However, I think this API could be extended further to be even more useful. In particular, if a Camera that was created by the world (and so is already accessible to Udon) is rendering, it would be great to be able to access the actual Camera object! Just like Unity's "Camera.current", but only limited to world-created Cameras. An API might look like this: VRCCameraSettings.CurrentCameraType: Enum consisting of the values "ScreenCamera", "PhotoCamera", "WorldCamera", or "Other". "WorldCamera" would be any camera created by the current world, i.e. a Camera that's accessible to Udon. "Other" would be anything else that isn't (yet!) accessible to Udon, e.g. avatar cameras or the screenshot camera. VRCCameraSettings.CurrentCamera: A reference to the current Camera object, just like Unity's Camera.current, except it's only set when CurrentCameraType is "WorldCamera". Otherwise, it's null.

A VRC Station option to lock a desktop player's mouse look to be vertical only while on a particular station. This would allow a station to control the horizontal rotation of the player without having the avatar be moving about with the mouse, and looking at their shoulders at the ends of the 180 deg range. This opens the floor for Udon controlled movement via mouse or other input that doesn't effect how the avatar appears to look horizontally.

Until recently I was under the impression that material swaps are the preferred way of having many different color themes for an avatar, as my assumption was that only the materials that are actively bound to a material slot would be persistent in VRAM. The recent changes to performance rank that reflects the VRAM used by all available textures gives me the indication instead that all materials are loaded and stay persistent, which is obviously not great for performance. Is there some reason why unused materials are not being unloaded, and if they are being unloaded (or at least are unpinned by Unity’s resource manager), would it make sense to change the performance rank accounting to only look at the largest materials that are ever bound to any given material slot?