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.
0
·
Feature Requests
SDK default Additive controller (vrc_AvatarV3IdleLayer) uses Write Defaults OFF on an additive layer, tripling non-zero blendshapes
SUMMARY The SDK's default Additive controller (vrc_AvatarV3IdleLayer) has a single layer whose blending mode is Additive, and both of its states ("Upright Idle" and "Empty") are Write Defaults OFF. When no WD OFF state in a playable layer above Additive covers it, every shape key that - is bound by some clip in the avatar's playable layers, and - has a non-zero value on the SkinnedMeshRenderer is shown at 3x its value (30 becomes 90). We observed this in the VRChat client on an affected avatar, and reproduced it with the minimal steps below in Gesture Manager. Setting only the Additive controller's states to Write Defaults ON fixes it, without changing the idle body motion. STEPS TO REPRODUCE Environment: Unity 2022.3.22f1, VRChat SDK Avatars 3.10.4, Gesture Manager 3.9.9 Use any humanoid avatar. On its face SkinnedMeshRenderer, set any shape key to 30. Create an FX controller with one layer (weight 1) containing two states: - "Idle" (default state): an empty clip, Write Defaults ON. - "Shape": a clip that animates that shape key, Write Defaults ON, with no transitions into it (it never plays). Assign this controller to the FX slot. Copy vrc_AvatarV3HandsLayer.controller (Packages/com.vrchat.avatars/Samples/AV3 Demo Assets/Animation/Controllers/) into Assets, turn Write Defaults ON on every state, and assign it to the Gesture slot. Leave Base, Additive, Action, Sitting, TPose and IKPose at their defaults. Play, stand idle, make no gesture. Expected: 30 Actual: 90 Copy vrc_AvatarV3IdleLayer.controller (same folder) into Assets, turn Write Defaults ON on both of its states, and assign it to the Additive slot. Actual: 30. The idle body motion is unchanged. Notes: - Only shape keys that some clip in the playable layers binds are affected, even if that clip never plays. - A value of 0 stays 0. - Base does not matter. - The error is hidden while any WD OFF state plays above Additive: the default Gesture controller, a WD OFF FX, or Action at weight 1 during an emote or AFK. This is why most avatars never notice it. WHY IT HAPPENS A WD OFF state asserts every animated binding of the avatar. For the bindings it does not animate itself, it fills in its held (bind-time) value. On the Additive input, which is additive, that dense pose is added on top of the lower layers twice: - once through the additive playable input, and - once more through the additive layer blend. So a shape key the Additive layer never touches still gets its default value added twice: d + 2d = 3d With an empty (zero-curve) clip in the same state, the value does not settle; it keeps growing every frame. WHY WD ON IS SAFE FOR THIS CONTROLLER We compared Additive = default (WD OFF) against a WD ON copy in every combination of: - Base: WD OFF / WD ON - Gesture: WD OFF / WD ON - FX: WD OFF / WD ON / mixed per layer - Action weight: 0 / 1 That is 24 configurations, 300 frames each, checking all 54 humanoid bones and the root. The idle clip was a muscle-only additive clip that moves the body by up to 8 degrees. Results: - Shape keys, Additive WD OFF: 3x whenever Gesture and FX are WD ON and Action is at weight 0. 1x otherwise. - Shape keys, Additive WD ON: 1x in all 24 configurations. - Humanoid motion: identical in all 24 configurations (0 degrees / 0 m difference between WD OFF and WD ON Additive). Humanoid muscles are applied as a single human pose, which Write Defaults does not affect, so the idle motion does not depend on this setting. On WD OFF avatars the change is invisible. On WD ON avatars it removes the error. Tools already apply this fix: VRCFury's "Fix Write Defaults" option marks all additive states WD ON. REQUEST Please set Write Defaults ON on both states of the SDK's default Additive controller, and on the client's internal equivalent if it mirrors the SDK asset. RELATED "[BUG] VRChat apply blend shape values 3 times" (2020, marked fixed) has the same symptom. The cause described here is in the default controller asset. https://feedback.vrchat.com/avatar-30/p/bug-vrchat-apply-blend-shape-values-3-times ------日本語------ 概要 SDK 既定の Additive コントローラ(vrc_AvatarV3IdleLayer)は、合成方式が Additive のレイヤー 1 枚だけでできていて、その 2 つのステート("Upright Idle" と "Empty")はどちらも Write Defaults OFF になっている。 Additive より上の Playable レイヤーに、これを覆う WD OFF のステートが無いとき、次の条件を満たすシェイプキーがすべて、その値の 3 倍で表示される(30 が 90 になる)。 - アバターの Playable レイヤー内のどこかのクリップが bind している - SkinnedMeshRenderer 上の値が 0 でない 問題が起きるアバターで、VRChat クライアント上での発生を確認した。また、下記の最小手順で Gesture Manager 上でも再現した。 Additive コントローラのステートだけを Write Defaults ON にすると、idle の体の動きを変えずに直る。 再現手順 環境: Unity 2022.3.22f1、VRChat SDK Avatars 3.10.4、Gesture Manager 3.9.9 任意の人型アバターを使う。顔の SkinnedMeshRenderer で、任意のシェイプキーを 30 にする。 レイヤー 1 枚(weight 1)の FX コントローラを作り、ステートを 2 つ置く。 - "Idle"(既定ステート): 空のクリップ、Write Defaults ON - "Shape": そのシェイプキーを動かすクリップ、Write Defaults ON。ここへの遷移は作らない(再生されない) このコントローラを FX 枠に割り当てる。 vrc_AvatarV3HandsLayer.controller (Packages/com.vrchat.avatars/Samples/AV3 Demo Assets/Animation/Controllers/) を Assets にコピーし、全ステートの Write Defaults を ON にして、Gesture 枠に割り当てる。 Base、Additive、Action、Sitting、TPose、IKPose は既定のままにする。 再生し、ジェスチャー無しで立ったままにする。 期待値: 30 実際: 90 vrc_AvatarV3IdleLayer.controller(同じフォルダ)を Assets にコピーし、2 つのステートの Write Defaults を ON にして、Additive 枠に割り当てる。 実際: 30。idle の体の動きは変わらない。 補足: - 影響を受けるのは、Playable レイヤー内のどこかのクリップが bind しているシェイプキーだけ。そのクリップが一度も再生されなくても対象になる。 - 値が 0 のものは 0 のまま。 - Base は関係しない。 - Additive より上で WD OFF のステートが再生されている間は、誤りが覆い隠される。既定の Gesture コントローラ、WD OFF の FX、エモートや AFK 中で weight 1 の Action がこれに当たる。多くのアバターで気付かれないのはこのため。 原因 WD OFF のステートは、アバターがアニメーションしている全 binding を主張する。自分がアニメーションしていない binding は、保持値(bind 時の値)で埋める。 Additive の入力は加算なので、この「密なポーズ」は下位レイヤーの上に 2 回足される。 - 1 回目: 加算の Playable 入力として - 2 回目: 加算レイヤーの合成として そのため Additive レイヤーが一切触らないシェイプキーにも、既定値が 2 回足される。 d + 2d = 3d 同じステートに空の(カーブ 0 本の)クリップを置くと、値は落ち着かず、毎フレーム増え続ける。 このコントローラを WD ON にしても安全である理由 Additive = 既定(WD OFF)と、WD ON のコピーを、次の全組み合わせで比較した。 - Base: WD OFF / WD ON - Gesture: WD OFF / WD ON - FX: WD OFF / WD ON / レイヤーごとに混在 - Action の weight: 0 / 1 計 24 構成、各 300 フレーム、人型の 54 ボーンすべてとルートを確認した。idle のクリップには、体を最大 8 度動かすマッスルだけの加算クリップを使った。 結果: - シェイプキー、Additive WD OFF: Gesture と FX が WD ON かつ Action の weight が 0 のとき 3 倍。それ以外は 1 倍。 - シェイプキー、Additive WD ON: 24 構成すべてで 1 倍。 - 人型の動き: 24 構成すべてで一致(Additive の WD OFF と WD ON の差は 0 度 / 0 m)。 人型のマッスルは「1 枚の人体ポーズ」として適用され、Write Defaults の影響を受けない。そのため idle の動きはこの設定に左右されない。 WD OFF のアバターでは変更は見た目に表れない。WD ON のアバターではこの誤りが消える。 この修正は既にツールでも行われている。VRCFury の "Fix Write Defaults" オプションは、加算レイヤーの全ステートを WD ON にする。 要望 SDK 既定の Additive コントローラの 2 つのステートを、Write Defaults ON にしてほしい。クライアント内部の同等品が SDK のアセットと同じなら、そちらも。 関連 "[BUG] VRChat apply blend shape values 3 times"(2020 年、修正済みとして完了)は症状が同じ。ここで述べる原因は、既定コントローラのアセットにある。 https://feedback.vrchat.com/avatar-30/p/bug-vrchat-apply-blend-shape-values-3-times
1
·
Bug Reports
·
tracked
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
56
Load More
→