SDK Bug & Feature Requests

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

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.

Please provide fallback shaders with VRCSDK and API to get them from material. There are multiple possible use cases like: To create avatar with exactly same look with and without Fallback - Currently, since we don't have fallback shaders, we cannot create avatar consistently looks same with and without fallback. To create Editor Extensions that shows the fallback-ed version of the avatar. - There are some editors exists but their implementation might can be different. - There is no documentation that explains the exact algorithm for parsing VRCFallback tag so we don't know which shader will be applied for wired VRCFallbackTag like ToonCutoutUnlit . To retrieve list of properties used in each fallback shader. - I want to get (current) list of properties supported in each fallback shader to remove unused properties from the material. - There are list of properties copied to fallback material on creator docs, but some fallback shader may not use some properties on the list (like Toon does not use most properties but _MainTex ).

title: VRCSDK should report error if the LipSync / Eyelids mode is BlendShape but not working because of bad settings In VRCAvatarDescriptor, LipSync and Eyelids setting have BlendShape mode. In this mode, VRChat automatically controls blendShapes to make LipSync and Eyelids work. However, all the following conditions must be met for this to work: Skinned Mesh Renderer must be specified in VRCAvatarDescriptor Mesh must be specified in the specified Skinned Mesh Renderer All BlendShapes for each feature must be specified in VRCAvatarDescriptor For example, normal (closing) mouse might be enough for 'pp' viseme but not specifying BlendShape for 'pp' viseme will make LipSync entirely not working. BlendShapes specified for each feature must be unique For example, One user mistakenly specified BlendShape for 'oh' is specified for 'ss' and unexpectedly all Viseme BlendShapes become not working. Those misconfigurations likely to cause unexpected behavior and hard to find the cause (especially for third and fourth cause). Therefore, I request VRCSDK to report error as a part of avatar validation if LipSync / Eyelids settings are broken. Quick fix is to change mode to ParameterOnly (LipSync) / None (Eyelids) so auto-fixing with changing mode is also good I think.

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.

With the SDK 3.10.2 update, the Avatar Expressions Menu editor received the following UX change: When targeting a Boolean parameter, the Value attribute is now hidden and is always treated as enabled, since that's the only valid option for a Boolean (true when activated, false when deactivated). While I understand the reasoning behind this change, it removed a useful workflow that was previously possible. Before this update, it was possible to create two menu controls targeting the same Boolean parameter: one with Value = True and another with Value = False. This allowed both controls to toggle the same parameter while only the control matching the current state would appear visually active. For example: Badge toggle (Value = True) Nameplate toggle (Value = False) When the Boolean is true, only the Badge toggle appears active. When it's false, only the Nameplate toggle appears active. This made it possible to represent two mutually exclusive states using a single Boolean while providing clear visual feedback in the Expressions Menu. Since the Value field is now hidden and always forced to true, this behavior is no longer possible. I'd like to see the Value option restored for Boolean parameters, even if it's tucked behind an advanced setting or warning. While the current behavior is simpler for most users, the previous implementation enabled legitimate use cases that are no longer possible.

When the Unity editor is in Prefab Mode, the SDK should show an error and some guide in the Builder tab. For beginners, trying to upload their avatar in Prefab Mode is a common mistake. They seem to encounter this situation by double-clicking on an avatar prefab they purchased. Even in Prefab Mode, the SDK shows the Builder tab and allows you to press the "Build & Test" and "Build & Publish" buttons. If the user presses the buttons, SDK shows "Building Avatar" Progress (see attached image) and does nothing after that. Also, there are no errors on the Console. Overall, the SDK doesn't care about this situation at all. It should be improved. Tested with SDK 3.7.1 ~~~ (Japanese translation) ~~~ タイトル：プレハブモードでアバターをビルドした時にエラーを表示するようにする Unity エディターがプレハブモードの時に、SDK は Builder タブにエラーと案内を表示するべきです。 初心者にとってプレハブモードでアバターをアップロードしようとするのは、よくある失敗です。彼らは購入したアバターのプレハブをダブルクリックすることで、この状況に遭遇するようです。 プレハブモードでも SDK は Builder タブを通常通り表示し、「Build & Test」と「Build & Publish」ボタンは押せるようになっています。ユーザーがボタンを押すと、SDK は「Building Avatar」の進行状況を表示し（添付画像を参照）、その後は何も行いません。また、コンソールにエラーはありません。 全体的に見て、SDK はこの状況をまったく考慮していません。改善すべきです。 SDK 3.7.1 で検証しました。

There are simple changes that can be done to UdonBehavior.cs that will enable full compatibility with the Unity Profiler. Please consider adding this to the SDK for use by developers. Attached are screenshots of 2 separate scripts and the resulting Profiler view with the changes I am referring to implemented.

A VRC_Pickup.Pickup() method would be nice. We have VRC_Pickup.Drop() which forces a pickup to be dropped. Pickup() would be a counterpart to this, forcing a grab. There's cool stuff you could do with this, I'm imagining better two-handed manipulation of pickups, and surely there is a lot of other inventory-related stuff you could do. Currently a common design for player inventory items is to spawn/teleport them to be floating in front of your face. Even if spawned at waist level or something, these items get in the way of clicking on other stuff, especially in desktop or mobile. It would be nice if udon could just put it in your hand, already grabbed, especially for non-vr players. How I imagine it could work: Call VRC_PIckup.Pickup(pickuphand) to basically emulate grabbing the item with that hand. If the hand's already grabbing something, this does nothing. Even though the grab input isn't actually in the down position, their hand is holding the pickup, until the grab input is actually pressed (which is then ignored because you're already grabbing) and then released (dropping it like normal). It might seem a little weird to have an object suddenly held in your hand without the input pressed, but still I think it's really worth having.

Improve or rollback the Control Panel UI/UX of the VRChatSDK to the 3.7.5 UI. The new UI in 3.7.6 has the following issues: ・The accordion titles are too large. ・"Name, Desc." and "Visibility" are placed next to each other, preventing further width reduction. ・Additional steps are required for "Build & Upload" and "Build & Test." The first two issues, in particular, severely degrade readability when docking the SDK or displaying it in a small window. At least in our team, we dock the Control Panel within Unity's tab system to prevent other windows from being hidden and to avoid wasting time dragging windows around. However, the current UI forces us to allocate extra space for the Control Panel, which is highly inconvenient. Additionally, the accordion titles do not need to be this large. ...Changing the build type is also cumbersome. (If we could request more, it would be ideal if the SDK Control Panel's width could be reduced to about 70% of its current size without breaking the layout.)