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.
Avatar Bill of Materials (ABOM)
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.
1
·
Feature Requests
Custom Avatar Fallback Not Selectable On Website Even When Meeting All Requirements
Avatars uploaded to meet custom fallback requirements cannot be selected as custom fallbacks from the website UI. Although the deprecation of fallbacks is listed (and active posts on these feedback forums indicate opposition to their removal), I have not been able to find any information about custom fallbacks not being uploadable anymore. Selecting a fallback from in-game has been removed some time back and outlined in an update post, but there is nothing about new avatars uploaded to be elligible as fallbacks being removed. As such, I assume this is a bug. docs.vrchat.com still lists custom avatar fallback creation process, and the avatar SDK upload panel still lists a notice about an avatar being elligible for fallback or not. Public avatars uploaded a while back, even if uploaded recently, by people I know (and which are not earmarked by VRC as fallbacks, e.g. CZ) are still selectable. It seems only newly created avatars are not selectable. Documentation and the SDK are incorrect, and if this is a known change that was not announced, this is extremely misleading and I think does nothing positive to the game whatsoever. Although impostors provide an effective, low-effort "quick fix" to avatar performance blocking, they are absolutely not a substitute to the very competent fallback system which incentivizes those who care to create much more optimized versions of avatars at substantially higher qualities than impostors could ever achieve. The feature still existing for avatars uploaded just a bit before is also annoying, as the system clearly remains in place and functional. Clarification on whether this is a bug or a known change would be greatly appreciated. Indication about whether Support can assist with making an avatar a fallback manually would also be appreciated.
0
·
Bug Reports
Show avatar visibility statistics to incentivize optimization
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.
0
·
Feature Requests
Load More
→