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.
VRC Constraints: Add per-axis Min/Max limits (one-directional constraints)
Summary Please add optional per-axis Min/Max limits to VRC Constraints (Rotation / Position / Parent), so a constraint can follow its source in only one direction. Use cases Skirts A skirt bone should move outward when the thigh swings forward, but stay in place when the thigh swings backward. Today a Rotation Constraint copies the thigh rotation in both directions. When the leg moves back, the skirt bone also rotates inward and clips into the leg. There is no way to say "follow +X only, ignore -X." When using colliders instead, skirts have to be made with some extra room around the legs. With this feature, tighter skirts would become possible, and they could be expressed without twisting or clipping into the legs. Shoulder area of outfits Shoulder parts such as puffed sleeves, shoulder frills, or collars could follow the arm only when it is raised, and stay in place when it is lowered. This would make the movement around the shoulders look much more natural. Accessories combined with PhysBones Many accessories can already be handled reasonably well with PhysBones. However, when a part at the end of a PhysBone chain needs more complex movement, it is difficult to control. With limits on constraints, such parts could follow the PhysBone movement only within a set range. Other examples: Accessories that should follow PhysBone movement, but only in one direction Armor plates that only rotate away from the body Hair or accessories that should not rotate past a certain angle Mechanical parts (levers, joints) with a fixed range of motion Proposed behavior Add a "Limits" section to Advanced Settings: Enable per axis (X / Y / Z) Min / Max value per axis Applied after the constraint is solved, in local space Example: Rotation X Min = 0, Max = 60 → the bone follows the source only between 0° and 60°. Negative rotation is clamped to 0. Optional extension: an output multiplier or remap (input range → output range). This would allow a 90° thigh rotation to produce a 30° skirt rotation, similar to Blender's Transformation constraint. This feature would expand the range of outfits and expressions creators can make. Skirts, sleeves, and accessories could move more naturally without clipping, and creators could build more refined designs. I believe this would make avatars more appealing and, in turn, add value to VRChat as a whole. This would also be useful for worlds. Related https://ask.vrchat.com/t/future-vrc-constraints-expansion/26576 https://feedback.vrchat.com/avatar-30/p/vrcconstraint-optimized-replacement-for-unity-constraints ―――――――――――――――――――― 【日本語】 概要 VRC Constraint(Rotation / Position / Parent)に、軸ごとの最小値・最大値の制限をオプションとして追加してほしいです。これにより、コンストレイントがソースの動きに一方向だけ追従できるようになります。 用途 スカート 太ももを前に振ったときはスカートのボーンを外側に動かし、後ろに振ったときはその場にとどめたいです。 現在の Rotation Constraint は、太ももの回転を両方向ともコピーします。脚を後ろに引くと、スカートのボーンも内側に回転して脚にめり込みます。「+X方向にだけ追従し、-X方向は無視する」と指定する方法がありません。 また、コライダーを使う場合は、脚のまわりに少し余裕を持たせてスカートを作る必要があります。この機能があれば、よりタイトなスカートを表現できるようになり、しかもねじれや食い込みのない形で表現できます。 衣装の肩まわり パフスリーブや肩のフリル、襟などの肩まわりのパーツを、腕を上げたときだけ追従させ、下ろしたときはその場にとどめることができます。これにより、肩まわりの動きをより自然に表現できるようになります。 PhysBone と組み合わせるアクセサリー 多くのアクセサリーは、PhysBone である程度対応できています。しかし、PhysBone の先で複雑な動きをさせたいパーツがある場合、それを制御するのは難しいです。コンストレイントに制限があれば、そうしたパーツを PhysBone の動きに一定の範囲内でだけ追従させることができます。 その他の例: PhysBone の動きに追従させつつ、一方向にだけ動かしたいアクセサリー 体から離れる方向にだけ回転させたい鎧のパーツ 一定の角度以上は回転させたくない髪やアクセサリー 可動範囲が決まっている機構部品(レバー、関節など) 提案する仕様 Advanced Settings に「Limits」セクションを追加: 軸ごと(X / Y / Z)に有効化できる 各軸に最小値・最大値を設定できる コンストレイントを解決した後に、ローカル空間で適用する 例:Rotation X の Min = 0、Max = 60 → ボーンは 0°〜60° の範囲でだけソースに追従する。マイナス方向の回転は 0 に制限される。 追加の拡張案:出力の倍率、または範囲変換(入力範囲 → 出力範囲)。これにより、太ももの 90° の回転をスカートの 30° の回転に変換できます。Blender の Transformation コンストレイントに近い機能です。 この機能によって、制作できる衣装や表現の幅が広がります。スカートや袖、アクセサリーがめり込まずに自然に動くようになり、より完成度の高いデザインを作れるようになります。それがアバターの魅力を高め、結果的に VRChat 全体の価値を高めることにつながると考えています。この機能はワールドでも役立つと思います。
0
·
Feature Requests
Adjust the Threshold for the “Shorter Than Average” Warning
Description Please consider adjusting the height threshold for the “Shorter Than Average” warning. Currently, the warning can appear on avatars that are shorter than the average human height, even when their height is completely intentional and normal for the avatar. For example, avatars around the height of Mamehinata and other commonly used smaller avatars are intentionally designed to be short. There is also a fairly large difference in typical avatar height between different avatar styles and communities. Because of this, I don’t think avatars that fall somewhere between the height of commonly used small avatars like Mamehinata and the typical height of larger Western avatars necessarily need to trigger a warning. Suggested Solution Instead of removing the “Shorter Than Average” warning entirely, lower the threshold at which it appears. The warning could be reserved for avatars that are unusually or extremely small, where their height may actually indicate an unintended configuration or could cause usability issues. This would keep the warning useful while avoiding unnecessary warnings for intentionally short avatars that are still within a normal range of avatar heights used in VRChat. ==Japanese== 「Shorter Than Average」警告が表示される身長の基準を調整してほしい 説明 「Shorter Than Average(平均より低い)」という警告が表示される身長の基準を調整してほしいです。 現在は、平均的な人間の身長より低いアバターの場合、その身長がアバターとして意図された正常なものであっても警告が表示されることがあります。 例えば、まめひなた程度の身長や、その他の一般的に使用されている小柄なアバターは、元々その身長になるよう意図的にデザインされています。また、アバターのスタイルやコミュニティによっても、一般的なアバターの身長にはかなり差があります。 そのため、まめひなたのような一般的な小柄アバターの身長から、比較的大きな海外アバターの一般的な身長までの範囲であれば、必ずしも「Shorter Than Average」という警告を表示する必要はないと思います。 提案 「Shorter Than Average」の警告そのものを削除するのではなく、警告が表示される身長の基準を、現在より低くしてほしいです。 通常のアバターとしては明らかに極端に小さく、意図しない設定になっている可能性や、実際に使い勝手に問題が発生する可能性がある場合にのみ警告を表示するようにすればよいと思います。 そうすることで、「Shorter Than Average」という警告の役割を残しながら、意図的に小柄に作られていて、VRChatでは一般的な範囲にあるアバターに不要な警告が表示されることを減らせると思います。
0
·
Feature Requests
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
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
→