Avatar Bugs & Feature Requests

I would like to propose an open standard for VRChat avatars called an Avatar Bill of Materials (ABOM). Today, many VRChat avatars are assembled from multiple assets: a base avatar, clothing, hairstyles, accessories, shaders, animations, tools, and other components purchased from different marketplaces or created by different authors. However, once these assets are imported into Unity and combined into a finished avatar, there is usually no standardized way to preserve information about where each component came from, whether it was obtained legitimately, which version is being used, or what license applies to it. This creates problems for both users and creators. Users may forget where an asset was purchased, lose track of dependencies, or have difficulty determining whether a particular use is permitted by the original license. Creators, meanwhile, have limited ways to distinguish legitimate users from unauthorized redistribution or extracted copies. I propose that VRChat, ideally in cooperation with major avatar marketplaces and tools such as BOOTH/pixiv, VRoid, Jinxxy, Gumroad, and others, develop an open ABOM specification. An ABOM could record information such as: Asset or product ID Creator or publisher Marketplace or source Asset version Dependency information Cryptographic hash or signature Proof that the asset was legitimately acquired Reference to the applicable license Information about whether a component is original, purchased, or derived from another asset The proof-of-purchase system should protect user privacy. It should not expose personal information, order numbers, or account names publicly. Ideally, marketplaces could issue signed or anonymous verification tokens that confirm only that an asset was legitimately obtained. The ABOM should not be DRM, and it should not be mandatory for uploading an avatar. Avatars without an ABOM should remain fully uploadable and usable. The purpose of ABOM should be to provide optional provenance and license metadata, not to create a requirement for participation in VRChat. Individual components should also be allowed to omit or hide provenance information when appropriate. For example, a user may have: Completely original assets they created themselves Private or unreleased assets Commissioned assets covered by confidentiality agreements Assets whose source should not be publicly disclosed Legacy assets for which complete provenance information is unavailable In such cases, an ABOM entry could simply mark the component as private, self-created, unverified, or not disclosed, without preventing the avatar from being uploaded. This distinction is important: ABOM should make legitimate provenance easier to prove when users want to provide it, but it should not force creators to disclose the full contents or origin of their avatars. The ABOM should also not be used to lock files, prevent modification, or restrict normal avatar creation workflows. It should instead provide standardized provenance and ownership metadata that can survive workflows such as: VRoid → Unity → VRChat or Purchased base avatar → Unity customization → VRChat The system could also support machine-readable license information. For example, licenses based on VN3 could potentially be checked by Unity tools, allowing creators to receive warnings when a planned use may conflict with the declared license terms. Such checks should be advisory rather than legal judgments. A tool might report: Allowed by declared license Not allowed by declared license Manual review required License information unavailable This would be especially useful when multiple assets with different licenses are combined into one avatar. An ABOM could also make long-term avatar maintenance much easier. Years later, a user could identify which asset version was used, where it came from, whether an update exists, and which dependencies are required. This could benefit several parts of the VRChat ecosystem at once: Better protection for avatar and asset creators Easier license compliance for users Better support for officially licensed IP avatars Reduced ambiguity around copyright-compliant avatars Improved dependency and version management Easier migration between tools such as VRoid and Unity Better distinction between legitimately purchased assets and unauthorized copies Optional proof of provenance without forcing disclosure Ideally, this would be developed as an open, interoperable specification rather than a VRChat-only proprietary format, so that marketplaces, avatar creation tools, Unity packages, and other social VR platforms could support the same metadata. VRChat avatars are increasingly complex creative works assembled from many different components. Treating them more like software packages with optional, privacy-respecting provenance and dependency metadata could make the ecosystem safer, easier to maintain, and more sustainable for both creators and users.

Currently, avatar performance ranks tell creators whether an avatar is expensive, but provide very little feedback about the practical consequence of that performance rank. If other users hide Poor/Very Poor avatars, or otherwise do not download the full avatar, the avatar author generally has no way of knowing. From their perspective, their avatar works and looks correct. This removes an important incentive to optimize. If we somehow had access to aggregate avatar visibility statistics to the avatar's statistics/performance information. For example: Last 7 days Full avatar downloads: 8,412 Impostor downloads: 3,105 Estimated visibility: 73% Where an approximate visibility metric could initially be calculated as: Full avatar downloads / (Full avatar downloads + impostor downloads) If VRChat already tracks cache comparisons or avatar/impostor selection separately from actual CDN transfers, those would be preferable to literal downloads. The objective is to measure how often the full avatar is selected compared with its impostor, while using aggregate data VRChat already collects or can collect cheaply. This creates a direct incentive to optimize. Instead of performance optimization only changing an SDK rating from Very Poor to Poor or Medium, creators can see that optimization resulted in more people actually seeing their avatar. Performance optimization currently benefits everybody except, visibly, the person doing the optimization. Users whose clients struggle can hide expensive avatars, use safety settings, or rely on impostors. The avatar wearer may never know this happened. Aggregate visibility statistics would close that feedback loop without identifying individual users or exposing anybody's personal safety settings. These statistics should be aggregate only. The avatar author should not be able to determine which users downloaded the full avatar, received an impostor, manually hid them, or otherwise chose not to render them.

(Note: This feature is still in development, so any of the details below might change before the final release.) The Avatar Optimizer runs automatically when you build or upload your avatar. It intelligently generates atlas textures and combines meshes and materials to reduce the number of draw calls, improving performance. You can configure the optimization settings to preserve certain blend shapes, skip generating atlas textures, or disable the optimizer entirely. You can preview optimized Avatars before uploading to check if the optimizations worked correctly. At first, only the Standard Lite and Toon Standard shaders will support material merging and texture atlasing. If you're a shader developer, our documentation will explain how to make your custom shader compatible with the avatar optimizer. Once we're ready, our goal is to test the avatar optimizer in a closed beta to collect more data on its usefulness and to inform our next steps.

Thinking outside the box here. Everyone focuses on these extremely arbitrary feeling ranks, and I think it's the wrong way to think about the problem. Computers are not equal, so the ranks cannot have equal meaning across them. In other words, what is Very Poor to the state of the art computer is vastly different than what is Very Poor to a wireless headset, or a laptop. Why not let the host computer decide for itself based on actual realtime metrics, letting the user configure and apply rules based on that? Provide sane defaults, like other video games give you quality presets "Low, Medium, High, Ultra". Just spit balling here (and some of these exist in similar ways already) but what if I had settings like: How many avatars make an instance light, cozy How many avatars make an instance busy, poppin How many avatars make an instance overloaded, omg-furality-club-world Frame rate impact of an avatar (show the cost to draw it somewhere?) Frame budget buckets for CPU time (draw calls?) Frame budget buckets for GPU memory Report about excessive shader compilation time/frame hitches. These ranks can adjust based on how populated a world is to maximize performance. I'm in a world with 3 other people, they can be in absolutely gargantuan avatars. But when the instance starts to fill up, the game has to cut back a little, those ranks reevaluate, and I might see some avatars fall back. [Frame budget] = [Current World Demand] + [[Av1%]+[Av2%]+[Av..n%]] <= [95% total compute available] Imagine the client observes Av2 needs way more of a share of resources than everyone else, AND we've reached a high water mark, then cut Av2s share. I hope these are ideas that spark some more out-of-the-box thinking about avatar performance.

It would be good to link such build-in variable to custom camera on avatar.

A popular use case for expressions on avatars is to do things like toggling objects on and off, adjusting blend shapes, and more. Setting up cases like these in an SDK project from scratch requires a fair amount of knowledge of how Unity and its animator system works, which isn’t always intuitive to users that are brand new to creating avatars. To help make it easier to set up common use cases like this, we’re working towards introducing a new component called the Action Driver. The fundamental idea of it is to let avatar creators bind parameters on their avatar directly to one or more “actions” that they want to trigger, which includes common tasks like turning game objects on and off. *Read more in our Developer Update .

For some avatars, the audio range being forcibly clamped at 40m is rather limiting. On some avatars that are used for specific purposes, audio involving music, effects, and interaction are relied upon for making the avatar what it is. The only solution if the audio is something like a music track, or a long-range sound effect (like on firearms, a common example) is being set to 2D, and thus, global. Setting the audio to global has the opposite intended effect most of the time, switching it from being a neat addition to "ok who is playing that audio, I am disabling their avatar immediately." Now the stated reason to the clamped range of 40 meters is "limitations are in place to prevent abuse and malicious sounds." (copied from here https://creators.vrchat.com/worlds/components/vrc_spatialaudiosource/#avatar-limitations ) However, 2D audio sources are still present, making a contradiction to this. Now whether or not this idea could be used I will include it anyway; raise the limitation to a max range of say, 500 meters, with an audio setting to either stay with the clamped 40, or have a much higher max range, with intervals for those who may want something in the middle. This setting could default to the current clamped 40, and only be changed by the user to increase the range of avatar audios they would like to hear.

(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

It's invisible to others. i can see the thumbs up my in screen.

won,t let me make an avatar or upload one