SDK Bug & Feature Requests

In the Graph of 3.8.1 the custom events list will only display one.

On the new Toon Standard shader if culling is set to Front or Off, the backfaces are rendered darker than they should be compared to the commonly used PC shaders. This is caused by the backface normals facing the wrong direction. The solution for rendering backface normals as expected it so flip the normals. This is the default in Poiyomi, and an option in Liltoon. Expected: Front and backfaces render with the same lighting. Actual: Backfaces are rendering much darker. Provided image shows four copies of the same avatar. The small feathers face the viewer like normal. The bottom right avatar is the traditional version, where the large feathers were duplicated and flipped, so they face the viewer. This avatar renders as expected. The remaining three copies have only one layer of the large feathers, all facing away from the viewer. Top left is the backfaces being rendered with flipped normals. Top right is a demonstration that when the backfaces are not flipped the results match the current output of Toon Standard. Bottom left is Toon Standard, which is not flipping backface normals. SDK Version: 3.8.1

When opening the VRChat SDK panel and navigating to the Builder tab, the VRC Per Platform Override component is automatically added to the root object of the avatar, even though I haven't done anything. Is this intended behavior? I have previously uploaded avatars using multi-platform settings (Android, iOS), but not with this avatar. So I suspect this automatic addition might be unintended.

When we uploaded multiple avatars in a row relatively quickly, we encountered an issue where the upload process would freeze without any error message shown on the console or in the log files. This issue comes from two main causes: Firstly, the VRChat SDK silently ignores exceptions that occur in VRC_SdkBuilder.RunExportAvatarBlueprint . The catch clauses has comment // Errors are handled by the error callback , but most of the exceptions do not initiate error callback, including this one. Secondly, the VRChat SDK does not handle the exception occurred when trying to delete the last uploaded .vrca file. Removing the last uploaded .vrca file is not a critical step in the upload process, so it should not cause upload to freeze. However, currently, if the deletion fails, the upload process will not continue, leading to a freeze. When we replaced catch clauses to catch (Exception e) { Debug.LogError(e); } , we were able to see the following error message in the console: System.IO.IOException: The process cannot access the file 'C:\Users\****\AppData\Local\Temp\****\****\637e8e6c-8eb6-4cd2-a651-241fb7aa6ed3.vrca' because it is being used by another process. at System.IO.FileSystem.DeleteFile (System.String fullPath) [0x0001a] in <27124aa0e30a41659b903b822b959bc7>:0 at System.IO.File.Delete (System.String path) [0x00014] in <27124aa0e30a41659b903b822b959bc7>:0 at VRC.SDK3.Builder.VRCAvatarBuilder.ExportCurrentAvatarResource (UnityEngine.Object avatarResource, System.Boolean testAsset, System.Boolean buildAssetBundle, System.String& avatarPrefabPath, System.Action`1[T] onProgress, System.Action`1[T] onContentProcessed) [0x003bc] in <81261fc1c1e94d15bda5671000ac0e16>:0 at VRC.SDK3.Builder.VRCAvatarBuilder.ExportAvatarBlueprint (UnityEngine.GameObject externalReference) [0x00021] in <81261fc1c1e94d15bda5671000ac0e16>:0 at VRC.SDK3A.Editor.VRCSdkControlPanelAvatarBuilder.Build (UnityEngine.GameObject target, System.Boolean testAvatar) [0x0040b] in .\Packages\com.vrchat.avatars\Editor\VRCSDK\SDK3A\VRCSdkControlPanelAvatarBuilder.cs:2600 UnityEngine.StackTraceUtility:ExtractStackTrace () UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[]) UnityEngine.Logger:Log (UnityEngine.LogType,object) UnityEngine.Debug:LogError (object) VRC.SDK3A.Editor.VRCSdkControlPanelAvatarBuilder/<Build>d__132:MoveNext () (at ./Packages/com.vrchat.avatars/Editor/VRCSDK/SDK3A/VRCSdkControlPanelAvatarBuilder.cs:2605) System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner:InvokeMoveNext (object) System.Threading.ExecutionContext:RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner:Run () System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation/<>c:<.cctor>b__7_0 (object) UnityEngine.UnitySynchronizationContext/WorkRequest:Invoke () UnityEngine.UnitySynchronizationContext:Exec () UnityEngine.UnitySynchronizationContext:ExecuteTasks () When we disabled the real-time protection of the antivirus software for the temporary folder, the upload process worked as expected without freezing. Therefore, we conclude that the issue is related to antivirus software holding a handle on the last uploaded .vrca file, which prevents it from being deleted.

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

When a humanoid collider (Head, Torso, Hand, Foot, Finger) collider is set to Disabled, it retains it's previous values and the transform value is still updated (not set to null, due to https://feedback.vrchat.com/sdk-bug-reports/p/custom-humanoid-collider-transforms-overridden ), in-game this results the collider still being set, even though it was "Disabled". This results broken "automatic" colliders ( https://feedback.vrchat.com/sdk-bug-reports/p/humanoid-colliders-may-divide-by-zero ) to still exist in-game.

While not exposed to the interface, the underlying transform a humanoid collider is assigned to can be overridden, however the inspector drawing code calls UpdateAutoColliders on each frame, which calls UpdateConfig , which in turn overrides any transform value with the one produced by VRCAvatarDescriptor.Calc____Collider methods, even when the collider is set to Custom configuration (or Disabled).

The SDK has "automatic" configuration for humanoid colliders (Head, Torso, Hand, Foot, and Fingers), the automatic radius calculation assumes that the transform scale in any axis will be greater than 0, when that isn't the case a divide by zero occurs, causing Radius to become Infinity.

When attempting to upload to both Windows and Android simultaneously, the Unity editor will switch between platforms, then build and upload, and then repeat this forever until the process is cancelled.

In the newly released NetworkCalling feature in SDK 3.8.1, network calling metadata is attached via an explicit separate argument to StoreProgram(). Unfortunately, due to this way of working, UASM is unable to actually assign this metadata on its own. It would be useful to have a dedicated section (as in code section, data section, "networkcalling" section?) for defining this metadata - looking at the current implementation, I don't see any reason why this can't be put into UASM.