Avatar Bugs & Feature Requests

Post about current Avatar bugs and Avatar Feature Requests. One item per post!
Non-constructive and off-topic posts will be moved or deleted.
[Feature Request] Comparison of animator parameters and quadrature.
I would like to see the VRC Avatar Parameter Driver functionality extended or a new State Behaviour that implements four arithmetic operations between parameters. It would be great if you could also add a function that allows exception handling by specifying a parameter of any bool type when a calculation result overflows or divides by zero. Another feature that would be very useful would be to add a State Behaviour that outputs the results of comparisons between Animator Parameters to a specified bool parameter. We believe that implementing these functions will enable more complex expressions and increase the readability of Animator compared to the implementation method using BlendTree, so please consider it. (The translation was done using Deepl and may contain unnatural expressions.) VRC Avatar Parameter Driverの機能拡張、もしくは新規のState Behaviourとしてパラメーター同士の四則演算を実装して欲しいです。 計算結果がオーバーフローした場合やゼロ除算が発生した場合に、任意のbool型のパラメーターを指定して例外処理などを行うことが可能な機能も追加していただけると嬉しいです。 そしてもう一つ、Animator Parameter同士の比較の結果を指定したbool型のパラメーターに出力するState Behaviourも追加していただければ非常に便利になると考えております。 これらの機能を実装することでより複雑な表現が可能になり、BlendTreeを用いた実装方法よりもAnimatorの可読性が上昇すると考えていますので、ぜひご検討ください。
0
VRC Update Breaks Avatar Menu Preview Sizes
As of June 24th 2025, VRChat 2025.2.3, build 1664, Avatar previews that I have spent hours fixing have been rebroken. In the latest particular case, my suspicion is the patch note "Avatars will now update constraints before they are scaled to fit in the preview UI." I was intentionally utilizing constraints in the preview pose animation to manipulate the scaling in the preview UI by not updating the constraint until after it was calculated. For example, in the second attached image, I was intentionally uploading the model with the arm at origin because somehow the mesh of the right arm would cause the preview to calculate the scale incorrectly, so I used constraints to restore the arm after calculations. The only remaining method I believe to resolve this Avatar Preview would be to pre-pose the resting pose of the .fbx in blender to have the arms down at her sides, but although the humanoid rig still functions, applying that armature modifier then causes the shoulders and so on to behave fundamentally different with IK as the arms are lifted again via locomotion/IK. I have gone back and forth with Fax (who recommended opening this canny) and other internal members for insight, and here's an overview of everything I know about avatar menu previews and what I've done to workaround them over the last few months to shed some light on what we've tried. ----- The menu preview is based on not just the unity bounds of the avatar, but more specifically the bounds that VRChat calculates during the first frame including your animators and any logic they perform (supposedly). Therefore things that may contribute to this (and multiple things may be contributing) Unity Bounds of an Avatar (like its meshes) FBX Bounds of an Avatar (like out of blender, including "exploding shapekeys" used for programs like Substance Painter) Positions of Gameobjects (such as like empty gameobjects that are floating around your avatar too far) And whether those things may or may not be animated on or off at runtime during the first frame ----- For example on our other AVM model, it had 3 underlying issues that each individually caused the preview to break so I had to find and fix each one The FBX uploaded literally by itself had a small preview. Solution: Posing the arms straight down like a pencil pose image.png The Blade in the left hand even existing broke the bounds. Possibly because in blender it was sideways at origin. I didn't want to go edit it in blender. Solution: I disabled for a few frames in the preview clip at the beginning before reenabling it for it to dissolve in I had a series of arbitrary empty gameobjects used as constraint sources that hovered around my body in a large area Solution: I scaled the root of the objects to 0, so all of its children that were scattered around your body all condensed into a single point, and i rescaled it back to 1 at runtime via animation ----- For the current problem avatar at hand (attached images), the primary issue we had was that the right cyberarm (which uses a duplicate armature) for some reason its mesh at tpose triggers the menu preview to shrink because I guess VRC thinks its horizontal bound was too big. Since this arm is still the same size of an arm and same mesh, but just on a duplicate armature, it seems that VRC treats parts of the mesh weightpainted to non-humanoid bones differently than to humanoid rig bones. The previous solution: I had to upload the avatar like this and use constraint animations to repair the arm at runtime. Latest VRChat update breaks this solution, as it seems to calculate the constraint regardless of when it is animated (even beyond the 1st frame bounds calculation) prior to applying the preview scaling. ----- Overall, please advise what can be done to work around these avatar preview menu issues, or implement some fixes/offer some alternatives to manipulate these avatar previews more consistently. It can be frustrating enough to constantly upload and iterate to test these previews alongside another current avatar preview bug where previewing the same avatar at different times can yield inconsistent sizes (which I'll open a separate canny about and link here)
1
Graphics.Blit Scripts for avatars
(Edit: Added "for avatars" to the post title. VRCGraphics.Blit is available for worlds, but not avatars.) The Shader Community's Request for Graphics.Blit What is Graphics.Blit? Graphics.Blit allows you to copy a source texture into a destination render texture using a shader. Being able to do this allows for shaders to write to render textures in a manner that does not require cameras ---- Why do we want Graphics.Blit? Currently shader creators are using cameras and render textures to emulate what Graphics.Blit does. Cameras were not made for this purpose and have a relatively high amount of overhead. On top of this, in order to effectively mimic Graphics.Blit we need two cameras to achieve the same effect. This doesn’t mean Graphics.Blit replaces cameras though, it allows for most use cases to run much quicker. ---- What uses this camera workaround currently? GPU particles . Anyone who's experimented with GPU particles knows how much faster these particles run compared to Unity's built in particle system. GPU particles in their current form can run a million particles in 1.43ms on the GPU. That's amazing already, but because we have to use cameras, ~0.7ms of CPU time(camera0 and camera1) is spent on updating the cameras. Graphics.Blit can bring the CPU time from ~0.7ms to ~0.07ms. GPU particles are not the only shader which will perform better using Graphics.Blit. Any shader which has uses a 2 camera and render texture setup will be faster using Graphics.Blit. Other use potential cases for Graphics.Blit * GPU dynamic bones * Cheap Gaussian blur * Fluid Simulation * Grass/Hair Simulation * Procedurally generating Data * Virtual Keyboard for mutes * AI for Shader pets following you around * Simple games and puzzles. Pong, Flappy bird, and the beginnings of Doom have been done with cameras already * Worlds with snow dynamic, rain puddles, and water ripples ---- Why should time be spent on Graphics.Blit when only shader creators will be using it? Even though this is going to mostly only effect shader creators, everyone benefits from this change. GPU particles have been released to the public for a while and has been the only way for VRChat users to get millions of particle without completely destroying FPS. Graphics.Blit would increase the room for innovation. ---- What would a Graphics.Blit component from the VRC SDK look like? We would like to see two scripts added to the SDK, a Blit Controller, and a Blit Component. The Blit Controller should be a component which can be added to game objects on avatars and worlds. The Blit Controller should also have one input, an array of Blit Components. The purpose of this controller is to handle the order in which each blit is executed. In order for a shader to store stateful information, there need to be two render textures and two blits. The order in which these two blits are run is important, and this controller handle that. The Blit Controller component should run Graphics.Blit for every Blit Component in the array, in order. The Blit Component should hold two inputs, a source texture and a destination texture. Where is the material at? Well in order to allow shaders to be animated in VRC we think that using the shared material from the mesh renderer on the game object would be ideal. The blit component should have a RunBlit function which takes the mesh renderer’s shared material and runs Graphics.Blit with the source,destination, and shared material. Also the RunBlit function should pass a couple extra bits of information to the shader. Namely the game object’s localToWorldMatrix, worldToLocalMatrix, and position. We think this is important because with Graphics.Blit you get no outside information. Some of the existing camera effect require position information. We have included a GitHub link which contains a mock implementation of what we think would be the best way to implement this for the use cases we have. It is under the MIT licence so feel free to use anything from our implementation. We want to make this as easy as possible on development time. Our mock implementation: https://github.com/Merlin-san/Blit-Component We aren't sure if components update on both PlayerLocal and Player for the local player, but updating more than once per frame should be avoided if that's the case. ---- Safety System Currently the render texture/camera work around that we use requires that you are friends with another user in order for that user to see the render texture. This was implemented before the safety system. If Graphics.Blit is implemented, render textures should be either apart of the safety system under "shaders", or its own category under "render textures" The shader community, Toocanzs, Merlin, Elixir, Xiexe, Blake447, Okano, snail, Tykesha, .Captain., Claw, Quantum, Nulliel, Naelstrof, Wakamu, 1001, Nave, Neitri, SCRN, Silent
53
Load More