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.
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
54
1695 - Avatar Performance Calculated Severely Incorrectly.
First of all, I know a major point of this update was Avatar Performance recalculation- but I can confirm it's very incorrect. I've handcounted Material Slots and tried reuploads of exact avatars and been met with exact data size yet completely different calculations of VRAM, Avatar Bounds, and most abundantly, Material Slots. It seems like every avatar I've uploaded has suddenly gained +1 Material Slot, despite both handcounting and VRChat's SDK's calculations. Examples: A Pokemon-Esque commission I did has a reported 32 Material Slots, ~118 mb VRAM, and no animated bounds at less than 2m per side (is smol.) These would Parallel the SDK within VRChat, and give perfectly symmetical in-game data. On Build 1695 a version of the avatar uploaded in March 2025 reports 18 Material Slots, 129.98 mb VRAM. The bounds are insane at 2860.40 per side. I double-checked, no avatar bounds are animated. However, a version of the exact same avatar (with no modifications) uploaded today, August 29th 2025 12am EST reports 33 Material Slots, 129.98 mb VRAM, and ludicrous asymmetrical bounds at 4798.35, 798.61, 1002.50. Once again, nothing abnormal within the avatar and nothing reported in within the SDK. And once again, absolutely nothing avatar-bounds related is animated- in fact, ERASING the FX and Action layered Animator Controllers does not change the Avatar Report at all. All enabled objects are found within range of the object. And no other animator controllers are present within the avatar's hierarchy. VRAM, Material Slots, and Bounds are all found to be calculated incorrectly. This issue is present on 20+ and counting separate uploads of avatars. Some have skyrocketing VRAM peaking 300+ MB post-update despite Windows platform overrided DXT1 and DXT5 Crunch Compression, some have +1 to +2 Material Slots. Some have -12 to -14 Material Slots. Some have astronomical bounds despite all instanced renders being online/enabled at once, reporting within the SDK being less than 5x6x5, and with not one animation affecting their transform. In other findings, deletion/negation of Animations providing Material Swaps as a functionality on Particle Systems, Mesh Renderers, Skinned Mesh Renderers, and Trails do not affect the miscalculation of "Material Slots", Bounds, nor VRAM. Nothing changes within avatar performance on deletion of their animator controllers besides download size. Most likely being the deletion of referenced Animation File Size. Another Example can be found on my Twitter: https://x.com/speedbuiz/status/1961261519640940710 Please do not dismiss this as my fault. I've posted to the canny before and been given the cold shoulder and ignored. I can confirm with multiple hours of discovery that these avatar performance calculations are completely incorrect. I expect there to be more abnormalities than just VRAM, Material Slots, and Bounds. Please reply with any discoveries, and please upvote this problem so VRChat can assist their Avatar Creators.
2
·

tracked

Load More