SDK Bug & Feature Requests

Using UdonGraph and UdonSharp, any attempt to load from a url (String, Image, and Video) fails to run, resulting in an UdonVM error. This issue can be reproduced in any project attempting to load a URL on the 3.10.2 SDK. The Graph shown in the screenshot never has OnStringLoadSuccess/Error trigger, as the error occurs during the LoadUrl step. The issue appears to stem from Udon communicating with UniTask. I have provided the resulting error using an UdonGraph here: ----- [UdonBehaviour] An exception occurred during Udon execution, this UdonBehaviour will be halted. VRC.Udon.VM.UdonVMException: The VM encountered an error! Exception Message: An exception occurred during EXTERN to 'VRCSDK3StringLoadingVRCStringDownloader.__LoadUrl__VRCSDKBaseVRCUrl_VRCUdonCommonInterfacesIUdonEventReceiver__SystemVoid'. Parameter Addresses: 0x00000000, 0x00000001 Method not found: Cysharp.Threading.Tasks.UniTask Cysharp.Threading.Tasks.UniTask.WaitWhile(System.Func`1<bool>,Cysharp.Threading.Tasks.PlayerLoopTiming,System.Threading.CancellationToken,bool)

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 building a world using Multi-platform build and publish with the user editor preference of Auto Refresh disabled the next platform will fail to build because UdonSharp cannot compile scripts that have not been compiled by Unity yet. Reproduction Steps Disable Auto Refresh in Unity Editor Preferences > Asset Pipeline. Attempt to multi-platform build and publish with at least 2 platforms. Notice the current platform will successfully build and upload. Wait for the SDK to automatically switch to the next platform. Notice UdonSharp fails the build and Unity starts compiling scripts after the fail. This was tested with SDK 3.10.1.

This is a less "official" kind of report, and I sincerely apologize if I come across as rude or anything of the sort. But the removal of various avatar uploading features for quest is completely unwarranted. For example: Alpha Blended particles. I have personally used and uploaded Alpha Blended particles to VRChat for quest on numerous avatars with absolutely zero issue, they worked perfectly fine. If I'm correct, they were removed for performance reasons.. this makes absolutely no sense to me or any of my other avatar creator friends. The performance issue regarding the quest build has absolutely nothing to do with particles and everything to do with avatars bypassing security measures through 3rd party SDKs. The avatars from illegal uploading should not be used as an excuse to punish those who use the official SDK. And even if It is 100% certain that particles are the reason for performance reduction. You guys seem to have already fixed that! There is a particle count limit on the quest side. I tested this myself, the maximum an avatar can spawn at one time is around 100K particles from a single system. This test was me trying to crash myself and willing participants with over a dozen particle systems all spawning the integer limit's number of particles. It instantly crashed PC users, but quest users stopped noticing increasing lag at a mere 150,000 particles being on at once.. thus proving the existence of the hard limit for particle count on the quest platform. And so the question I have is, if there is already hard limits for that, why is Alpha Blended still incompatible? If it was truly removed because of performance, and that has been fixed by now, why not add it back? As for the other shaders in VRChat/Mobile, What I would like to request is VRChat/Mobile/Toon Standard (Outline) become quest compatible, specifically the outline feature. It is 100% possible to do this, I have seen numerous quest exclusive games that run on unity use shader based outlines. Additionally, I have seen some VRChat avatars on quest that were uploaded through an illegal SDK use that specific feature from the popular Poiyomi Shader. If I'm not mistaken, the entire concept of /Toon Standard and /Toon Standard (Outline), was almost entirely inspired from Poiyomi Shaders. So why is this not a feature even though its in the VRChat/Mobile shader pack? Respectfully, if performance complaints are truly the only reason as to why these features are not in the game, then that is not the game's fault/problem, it is the development team that is at fault. Instead of coddling the complaints of players that are too young to even play the game, maybe let them crash a few times to teach them to use YOUR features and hide an avatar or two. Its not the game's fault for an 8 year old entering a 40 person lobby, only to then MANUALLY show EVERYONE's avatar, and then REFUSE to hide them when they start lagging. The reason I point out the word "manually" is your game's DEFAULT safety settings literally prevent certain thresholds of avatar limits from being shown automatically. In order to change those thresholds you have to specifically go into your settings and mess with them manually. At that point is it really a performance issue if they literally ask for it? Take this for example: lets say hypothetically a massive game were to be fully released on mobile. Specifically meant for high end mobile devices, I then download it onto my cheap phone and crank the settings as high as they can go. That is an example of what the "performance" issue in VRChat is, its people refusing to optimize with features you give them. Instead of lowering the limits for quest every time some new crashing method gets figured out, maybe inform the people of the features specifically made to protect yourself from avatars? Lowering limits for uploading to the quest platform (which if I'm not mistaken is the larger side of the game's player base) is just making it worse. As much as many others would deny this, VRChat would be absolutely nothing without its creativity, its literally the entire game. Removing/Lowering creativity because people refuse to optimize is just bad business. There are always going to be crashers, there are always going to be laggers, there are always going to be people that ruin it for everyone else. That's just how gaming works. Punishing everyone else just because of a few bad actors is a good way of getting everyone to walk away from the game. All in All either remove the incompatible shaders from the /Mobile selection, or make everything in /Mobile compatible with quest. Its getting genuinely annoying when I make a cool looking avatar with cool looking effects only to be slapped in the face with it being incompatible with quest even though I am using /Mobile shaders.

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.

With the current stickers functionality, world creators can only choose to enable/disable it for their world. This is a source of unintended conflict when it comes to world preservation and event management. We propose the following features (1) Bounding box control of stickers pasting area (2) Control of stickers pasting area by each MeshRenderer (3) Control of stickers pasting area by layer We would like to add SDK components that can be controlled on the world creator side and a function to visually detect the area that can be pasted (for example, UX that Raycast shows blue for possible pasting and red for not possible). 現状のstickersの機能ですと、ワールドクリエイターは自分のワールドに有効/無効の選択をすることしかできません。 これは世界観の保持やイベント運営に当たり、意図しない紛争を招く原因になります。 以下のような機能を提案します。 ①バウンディングボックスによるstickersの貼り付けエリアの制御 ②MeshRendererごとにstickersの貼り付けエリアの制御 ③レイヤーによるstickersの貼り付けエリアの制御 ワールドクリエイター側で制御できるSDKコンポーネントの追加と 貼り付け可能エリアを視覚で感知できる機能 (例えばRayCastで貼り付け可能は青、不可能は赤のようなUX)を希望します。

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).

This would be usefull if as a world creator we dont want stikers on video players, mirrors or user posters and menus. But at the same time we dont want to prevent users to post stikers anywhere else.

Currently udon doesn't allow for you to create a cubemap rendertexture in code, because TextureDimension.Cube is needed to set up the RT, but is not exposed More importantly, in Unity you cannot use 'blit' to paint faces onto a cubemap rendertexture, there's a unique Graphics.CopyTexture function that is allowed to edit cubemap slices, but that isn't exposed to Udon. Please consider exposing these simple functions, or giving us other ways of creating a cubemap at runtime!

UI>Scroll View(Scroll Rect) is moved by character moves(wasd or stick input). When using Scrollbar, I can fix it by Navigation: Automatic to None. But ScrollVIew doesn't have Navigateion option. In addition, I deteled two Scrollbers(Horizontal and vertical) but ScrollView moved. So I think there are bugs between ScrollView(or Scroll Rect) and VRCSDK. Version: VRCSDK3-WORLD-2020.09.25.00.08_Public Description of the bug: UI>Scroll View(Scroll Rect) is moved by character moves(wasd or stick input). Steps to reproduce (how did you encounter the bug?): Create new Canvas and add UI>ScrollView. Attach VRC Ui Shape to Canvas and change Render Mode to World Space. Attach Vertical Layout Group and Content Size Fitter to Content. Add some Panels having Layout Element to Content. In VRChat, the ScrollView moves with I move.