SDK Bug & Feature Requests

The Network ID Utility can have massive performance issues when working with more than a couple dozens of objects. This can be painful for larger projects especially since now we must retain Network IDs for persistence to function properly. Solution 1: Make a paging system so we can navigate the whole list chunks at a time. Older websites did this to prevent server and web performance issues. We could be given options to view 10/20/25/50/100 or a custom number of objects per page. Solution 2: Change the backend of how objects are listed to only display the ones that could be visible from that window. This would allow infinite scrolling with no pages like Google search or Youtube but can take a bit to get working correctly with a Scroll View. Solution 3: Like solution 2 but using UI Toolkit to have a load time for initialization but is steady after load. I would appreciate if it did not regenerate after clicking an option that changes the data, causing you to wait the full load time again to see the updated list.

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.

If the Aim Vector and Up Vector are modified from their default values, the results may differ between Unity Aim Constraint and VRC Aim Constraint. Note: This occurs when the World Up Type is set to None, but similar issues may arise with other types as well. This issue also occurs with automatic conversion and affects avatars that use Unity constraints uploaded in the past.

As reported by GotoFinal in https://github.com/bdunderscore/modular-avatar/issues/1408#issuecomment-2599998015 - VRCPhysBoneEditor calls EditorUtility.SetDirty right after calling ApplyModifiedProperties on the editor SerializedObject. This is redundant, as SerializedObject handles setting objects dirty, and also broken in that it only hits the _first_ target in a multi-select. Calling SetDirty generates a ObjectChangeKind.ChangeScene event on the ObjectChangeEventStream; a well-behaved editor plugin would then need to scan the entire scene for changes, and this scanning resulted in performance issues in NDMF and Modular Avatar. Given that this SetDirty call isn't needed, please remove this call to avoid generating these unhelpful ChangeScene events.

Many NullReferenceException happens during the import process. You will fail to do even a simple "loop back test". Repro steps Create a scene having a VRCSceneDescriptor and an UdonBehavior at the minimum. Open Network ID Import and Export Utility https://creators.vrchat.com/worlds/udon/networking/network-id-utility/#network-id-import-and-export-utility Press Regenerate Scene IDs and confirm the dialog Press Export and save it to a file Press Clear Scene IDs and confirm the dialog Press Import and select the file you have just saved. The utility shows the object(s). Press Accept All or Select Then, the Console shows NullReferenceException errors Environment Tested with SDK 3.7.0 Worlds. This seems to happen from 3.5.2 Log The head part of the exception: NullReferenceException: Object reference not set to an instance of an object VRCNetworkIDUtility.<DetectConflicts>g__DoTypesMatch|28_6 (VRCNetworkIDUtility+NetworkObjectRef scene, VRCNetworkIDUtility+NetworkObjectRef loaded) (at ./Packages/com.vrchat.base/Editor/VRCSDK/Dependencies/VRChat/VRCNetworkIDUtility.cs:550) VRCNetworkIDUtility.DetectConflicts (System.Collections.Generic.Dictionary`2[TKey,TValue] loadedRefs, System.Collections.Generic.List`1[T] conflictList) (at ./Packages/com.vrchat.base/Editor/VRCSDK/Dependencies/VRChat/VRCNetworkIDUtility.cs:520) VRCNetworkIDUtility.OnGUI () (at ./Packages/com.vrchat.base/Editor/VRCSDK/Dependencies/VRChat/VRCNetworkIDUtility.cs:297) Note The NullReferenceException happens when accessing NetworkObjectRef.typeNames . Some implementation of INetworkIDContainer has the issue, maybe, UdonBehavior . INetworkIDContainer.NetworkIDCollection is typed List<NetworkIDPair> Some element of it has the null as NetworkIDPair.SerializedTypeNames

SDK 3.7.5 Client Build 1582 In testing matcap fallback behavior I found that I was unable to preview a matcap fallback under any circumstance. The two materials on top are testing shader tags (which I obviously could not get to work) after which I decided to test the VRC shader and found not even that was working.

After updating my project's SDKs (base and avatars) to 3.8.0 via VRC Creator Companion physbones completely ignore realtime component tweaks while in play mode. Tweaks to any settings (pull, spring, gravity, immoble, limits, etc) are not respected and physbones continue to use settings only set previously in edit mode. This completely removes the ability to tweak and observe results in realtime. Reverting base and avatars SDKs back to 3.7.6 fixes the issue.

Detail albedo and normal maps seem to have a pixilation effect, which does not have to do with the resolution or filtering settings of the texture.

The code below works in SDK 3.5.1, but not in SDK 3.5.2, in Unity editor. (It causes an 'Object reference not set to an instance of an object' exception.) (using VRC.SDK3.Components;) VRCObjectSync sync = GetComponent<VRCObjectSync>(); sync.SetGravity(true); This issue occurs even though the 'sync' variable is not null.

Discovered that on SDK 3.7.0, VRC Parent and Position Constraint cause the object to move away from the source if the object size is 0, which can be fixed as long as the object size is not 0 (can be 0.0001). This problem show up on VRC because it automatically convert Unity Constraint into VRC Contraint which causes player Nameplate/Nametag to be really high up.