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
57
[SDK 3.10.6] Mouth facial tracking does not work with test-built avatars when using Selfie Expression
SDK 3.10.6で作成したフェイストラッキング対応アバターについて、Build & Testでテストビルドを行い、VRChat上で使用した際に不具合が発生します。 この問題はテストビルドしたアバターでのみ発生し、同一のアバター設定でアップロードしたアバターでは再現しません。 具体的な現象の説明 テストビルドしたアバターでSelfie Expressionを実行すると、口周りのフェイストラッキングだけが正常に動作せず、音声によるリップシンクでの口の動きのみしか確認出来ません。 同じアバターをBuild & Publishで正式にアップロードし、VRChat上でそのアバターを使用した状態でSelfie Expressionを実行した場合は、口周りを含めてフェイストラッキングが正常に動作します。 目など、口以外のフェイストラッキングはどちらでも正常に動作しています。 再現条件 1.SDK 3.10.6を使用してフェイストラッキング対応アバターを作成する。 Build & Testでアバターをテストビルドする。 3.VRChat上でテストビルドしたアバターを使用する。 4.Selfie Expressionを実行する。 5.発声せず口を動かし、口が動かない事を確認する。 フェイストラッキングのシェイプキーの割り当てに関する設定では部分的に欠けこそあるものの、おおよその動きを出来る程度の口の動きを割り当てた上でこの現象を確認しています。 Face Trackingに関する設定が選択可能な項目(LipSync,Eye Gaze Mode,Eyelid Type)は全てFace Trackingを使う物にしており、Face TrackingのUse All Tracking Keysのチェックボックスも有効にしています。アップロードしたアバターでは動作する事で示しているように各KeyのMutiplierが極端に低かったり0だったりする事もありません。 なお、デバッグ画面のFace Trackingの画面ではJawOpenなどの値が口の開閉に応じて正常に変化することを確認しており、フェイストラッキング用のパラメーター自体は不具合状況下でも動いてはいるようです。 Description I have encountered an issue with a face tracking-enabled avatar created using SDK 3.10.6. This issue only occurs with avatars built using Build & Test. It cannot be reproduced with the uploaded version of the same avatar using identical settings. Details When I activate Selfie Expression while using the test-built avatar, only mouth-related facial tracking fails to work correctly. The only mouth movement I can observe is from voice-based lip-sync. However, when I upload the same avatar using Build & Publish and activate Selfie Expression while using the uploaded avatar in VRChat, facial tracking works correctly, including mouth tracking. Other facial tracking features, such as eye tracking, work correctly in both cases. Steps to Reproduce 1.Create a face tracking-enabled avatar using SDK 3.10.6. Build the avatar using Build & Test. 3.Use the test-built avatar in VRChat. 4.Activate Selfie Expression. 5.Move your mouth without making any sounds and observe that the avatar's mouth does not move. Additional Information Although some of the facial tracking blendshape assignments are not yet implemented, I have assigned enough mouth-related blendshapes to reproduce most of the mouth movements. I confirmed this issue with that configuration. All available settings related to Face Tracking (LipSync, Eye Gaze Mode, and Eyelid Type) are configured to use Face Tracking. The "Use All Tracking Keys" checkbox is also enabled. As demonstrated by the fact that the uploaded avatar works correctly, none of the multipliers for the individual keys are set to extremely low values or zero. Additionally, on the Face Tracking debug screen, I have confirmed that values such as JawOpen change correctly in response to mouth movements. This indicates that the facial tracking parameters themselves appear to be functioning even when the issue occurs.
0
·
Bug Reports
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
`Eye Look` with Native FT causes random eye offsets on remotes
With the new Native FT update, windows build 1937, I've been having an issue where remote clients see my avatar's eyes with set random offsets. Locally, everything is 100% perfect all the time. Only remotes have this offset issue. After tracking the issue down, I've found that if I disable Eye Look completely in the VRC Avatar Descriptor, the offset no longer happens on remotes. (See included VRC Desc picture for broken version) It appears if you drive your own eye look bone rotations in your own animator while Eye Look setting is enabled (even with Eye-gaze field set to Face Tracking ), an offset is applied to remotes when your avatar is loaded in. Possibly an additional problem that I have 'none' set as my eye bones (defaulting to use Unity-Avatar's set Eye Bones when none?) If I had to guess, when the remote loads in your avatar, the stimulated Eye-Gaze functionality is on by default applying bone rotations and/or Eye Look param value changes. Then, the avatar is initializes with its networked params. Which freezes the simulated Eye-Gaze baking that offset into the remote user's avatar. This offset may be baked into the bone rotations, or the Native FT Eye Look parameter itself. If this issue is an intended conflicting behavior, perhaps a warning help-box in the VRC Avi Desc and an additional note in the documentation, would really help. Reproducible by: Use an avatar that uses bone rotations for its eye tracking. (you can use my linked avatar) Enable Eye Look with Face Tracking Eye-Gaze setting enabled. Drive your eye rotations via Native FT Eye Look params. Join a world with another remote user. Have the remote user observe the potential offset in the positions of the eyes. Included video: Note how when I switch avatars, the Remote eyes are completely different than the local. Including the ears rotations as they are also driven by Native FT Eye Look params. This public avatar uploaded with Eye Look enabled demonstrates this issue well. (yeah its creepy xD Just a stripped down version of my avatar): https://vrchat.com/home/avatar/avtr_b1e1f772-1b05-4556-965c-1ddeb5a8a0fc
1
·
Bug Reports
·
tracked
Load More
→