SDK Bug & Feature Requests

I developed a prefab that uses finalIK raycasts, but switched to VRC Raycasts for convenience's sake People started reporting that the prefab was triggering when it shouldn't, so I looked into it My raycasts are set up to snap to end and disable the object when the raycast doesn't connect, and in-editor it does, but in-game it doesn't. The two contacts floating out is where the prefab is always supposed to reset to, but as you can see in the second image, if I walk through one of the raycasts it gets stuck. Also they are not disabled The objects being controlled by the raycast aren't parented to the raycast if that's relevant

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

I believe it is time to get a solution to the most plaguing issue (in my opinion) of AVPro: Audio Filters I do not think this is a "can't fix" situation. In this proposal I will go over the problem, considerations that have been discussed historically, and the solution I believe is feasible to implement with working sample code. ### Previous Cannys 1) https://feedback.vrchat.com/open-beta/p/986-avpro-player-ignores-lowpass-reverb-and-other-filters 2) https://feedback.vrchat.com/sdk-bug-reports/p/avpro-video-player-audio-filter-issue 3) https://feedback.vrchat.com/sdk-bug-reports/p/sound-effects-are-not-applied-to-audiosource-using-avpro-that-comes-with-sdk3 4) https://feedback.vrchat.com/feature-requests/p/usharpvideo-stream-audio-does-not-support-filters ### Crux of the issue As previously discussed in above canny #1, the current way of handling the AVPro speaker component (type named AudioOutput ) is that the component is implicitly created via AddComponent on the same game object. This has the critical drawback of being unable to respect any audio filters due to the DSP filter chain being _component order dependent_. The second half of this issue is that Unity has no runtime native way to change the ordering of components without fully reconstructing the references. This causes very obvious issues in regards to dependent scene references. (TCL's comment in canny #1 clarifies this as well) ### What has been considered Detecting and destroying/rebuilding known filter components after the implicit component is added. This is bad because all scene references to those components would be lost (eg: UI Events or public Udon variables). To avoid the lost components issue, a full scene search would be required in order to update the references which is costly and fragile. Placeholder components (shims) for each filter type that gets implicitly created after the implicit AudioOutput This is bad because it does not allow users to reference the actual filter components in the inspector (namely an issue for UI Events) Allow adding the AudioOutput script manually in scene and have the speaker search for it before trying to implicitly add the component. This is bad because it requires that the user import the AVProTrial package to be able to use built-in unity audio filters. This needs to be compatible with situations where the user does not wish to import that package so the dependency is decoupled from the feature itself. ### Proposed Solution A shim script that inherits from the AudioOutput class combined with a compiler flag for detecting if AVPro is present, and if not, then have a stub type of the _same namespace and type name_ which is _ONLY_ present in the sdk. Then update the VRCAVProVideoSpeaker to check for the existence of the shim component before creating an implicit AudioOutput, using it instead if found on the game object. This ensures that when the main shim script is loaded in editor, it is already a valid AudioOutput component and the component order is correctly retained so the Audio Filters will work correctly. In the SDK, the script type will check for the existence of AVPro through a version define, and if NOT present, will enable the AudioOutput stub class of the same namespace. An example of what it might be like: https://gist.github.com/techanon/41efc336604e148dde55862bff1778d9 I've tested this specific example in editor and it works there. Can't test in-client obviously.

When physbone rotations are limited, the effects of physics settings such as gravity, as well as pulling on the physbone, will cause the "locked out" rotation to travel up the chain, for example: Making a vertical line of 3 bones and limiting the rotation to 10 degrees, then grabbing the bone at the bottom and moving it beyond 10 degrees will cause the parent to then rotate to follow it (since they're linked together) However this same behavior does not extend to collisions, pushing the bone described above with a collider will only cause it to move and lock out at 10 degrees, and won't travel up the chain to push the parent, I see this as a bug as the behavior differs depending on interaction method. Please allow the forces induced by colliders to travel up the chain (note that some physbones may have depended on the old behavior, so a physbone version bump i.e. 1.2 might be necessary). This currently makes setups like the ones in the attached images only function for grabbing, not collision (hinge rotation on root bone affects the glasses, collision radius set to 0.015 but reduced to 0 on the root bone via curve, dummy bone set to to overlap the glasses frame with collision, to provide a wider point of contact than what would be possible otherwise, hinge rotation set to 0 on the dummy bones, immediately locking out their rotation, which should cause any force induced on them to travel up the chain).

After testing, different of standard unity editor behavior where turning off auto graphics API for linux lets you reorder the graphics APIS and make unity try to first load with vulkan, VRC SDK on editor unload re-enables Auto Graphics API for linux, meaning that on the next project startup it will launch on OpenGLCore which is a broke renderer, and much slower, and since it is a different renderer this also triggers the assets to be rebuilt making the startup time infuriately long. This behavior is different of standard unity editor behavior that maintains the selected option across many restarts of the editor, this behavior only happens when VRC SDK is installed on the project. Tested with an empty VRC Avatar project to confirm it is in fact VRC SDK causing this behavior. Attached are 2 images, showing how OpenGL is rendering in a completely broken manner, while vulkan renders normally. Hardware & Software Specs: Operating System: CachyOS Linux KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0 Kernel Version: 7.0.3-1-cachyos (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 4600G with Radeon Graphics Memory: 32 GiB of RAM (27.3 GiB usable) Graphics Processor 1: AMD Radeon RX 7700 XT Graphics Processor 2: AMD Radeon Graphics Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C96 System Version: 1.0 Unity 2022.3.22f1 Available Graphics APIS: Vulkan OpenGLCore Tested on an empty project created with Unity Hub (shows correct behavior) And on a VRChat Avatar project created with ALCOM (shows wrong behavior [keeps resetting to OpenGL on editor exit]) Created from: https://help.vrchat.com/hc/en-us/requests/692576

SDK version 3.10.3 The explanation states that if you set the Playback order in the Play Audio Behaviour component to Parameter, depending on the number of the int, it will play said audioclip. no matter which element number or parameter int number, no audio gets played. When I check the Audio Source afterwards it should have played something, the "AudioClip Field" is completely empty, even though there is a registered audioclip in the Behaviour component. If I add more clips to it and change the parameter int to any number that corresponds to the clip number, still nothing gets played.

The contact system is limited to 60 updates per second, in scenarios over 60 fps, the contacts will maintain information from a prior frame, for systems expecting an update every frame, this leads to incorrect assumptions, which can break logic in unexpected ways. This can be prevented by adding a parameter to indicate whether contacts have updated this frame (i.e. ContactUpdate ), this would allow us to short-circuit every contact-based transition to only evaluate when we know contacts have up-to-date values, avoiding these problems. An inverse of the parameter (i.e. ContactUpdateSkipped) can currently be implemented by using a Proximity contact and setting it's value to non-0 every frame, on frames that the contact receives an update, the value will be overridden back to 0, adding the parameter as a boolean in the controller means that contacts have updated when the parameter is false (can undo the inverse behavior by adding an overlapping sender, but that adds another runtime component).

1) Create new project 2) Load up your asset(s) and modify the avatar 3) Go to SDK and login 4) Once logged in, Builder tab is completely locked out 5) Go to other tab (Authentication etc.) 6) Go back to builder tab -> all options are now unlocked And by locked out, I mean all options are greyed out. I do have faint memory of this happening as well when I come back to the project after closing Unity and wanting to update the avatar, but I am not entirely sure. OS: Win 11 Pro (latest at the time of writing) SDK: 3.10.3

The laser pointer that is used in world UI or to point at an interact/pickup currently does not have a native way of checking where that is nor what VR hand is showing the laser. This requests for a function or event to get the hand and Ray (to be used with a Physics Raycast) that references where the laser pointer is and a way to request for the Ray in the off-hand. This would be extremely helpful in creating pointer based controls (like click drag) for 2D color pickers, showing both lasers for an in-world keyboard, custom interactions, drawing on a 2D canvas, etc. I made an Udon prefab that's able to estimate these pointers but it would be nice if this was a native SDK feature: https://bobystarvrc.booth.pm/items/5007241

Since there is no benefit to using crunch compression and it only lowers the texture quality and causes lag when loading in the avatars due to uncrunching, I think there should be a warning for that inside the SDK and maybe an auto fix button to remove crunching entirely. Similar to switching box mipmaps to kaiser. I know you've already spoken against crunching in one of the developer updates in the past, but having this information should be more on display rather than just a mention in a blog. Developer update in question: https://ask.vrchat.com/t/developer-update-14-march-2024/23401