Avatar Bugs & Feature Requests

Animated Scaling for bone with Physbone applied will Jitter and never stop moving when hit with a collider. A Prox Contact receiver is used to Scale bone size 0 - 1 Physbone are applied normally Separate both parts work. Together Physbones scale but rotation is jittering and won't go in rest state On SDK 3.10.1 and 3.10.2 broken

When the following conditions are met, a PB placed under an object with a Constraint setting will not follow the Constraint’s movement, regardless of whether it is Local or Remote. (Contacts follow correctly without any issues.) An animation within the Animator manipulates the Transform of the object that has the Constraint setting. (This applies even if it's in an isolated state.) The Constraint applied to the object is in an enabled state. Once the Constraint is disabled and the animation is able to move the object, the PB starts following to the correct position. (The avatar where this bug was discovered has a somewhat complex setup, so there may be other contributing factors.) The avatar ID where the issue occurs is as follows: avtr_d45ac5bc-cb20-4bce-8c03-bf45e81f0dec SDK: 3.8.0 BuildVersion: 1628 --------------------------------------------------------------------------------------------------------------------- [JP] [特定条件下でPBはConstraint設定されたObjectの動きに追従しません。] 以下の条件を満たすとき、Constraint設定されたObjectの配下に設定されたPBがLocal/Remote問わずConstraintの動きに追従しません。 (Contactは問題なく追従します。) ①Animatorの中にConstraint設定したObjectのTransformを操作するAnimationが含まれている。 (孤立したStateでも同様) ②Objectに設定されたConstraintが有効状態になっている。 Constraintが無効になりAnimationで動かせるようになると、PBは正しい位置へ追従するようになります。 (バグを発見したアバターは少々複雑な作りをしているため、他にも原因があるかもしれません。)

Follow up to previous post - issue now 100% determined. Scaling a bone in y axis (along bone length) that is a bone for a physbone root transform will cause physbone Jitter. This was introduced with the update that made boops public. Avatar was previously fine. Tested on multiple bones (ears, whiskers, hair, tongue) on a fresh upload default Awtter avatar, as well as another avatars ears - issue was repeatable in both avatars. It appears to be only the Y axis. I have not tried negative scaling values. physbone parameters not at fault. Impossible to get natural motion and eliminate jitter. Jitter frequency is high in VR, and less noticeable in desktop mode. See attached video of issue replicated on all root transform bones on Awtter.

With the recent-ish change that makes particle lights correctly count towards your total light count, I noticed a possible discrepancy with the total count. Steps to recreate: Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Limit Maximum Lights to 1. Upload to VRChat Observe avatar details of avatar. Lights will be listed as 2/1 Example of an avatar that only has 1 Max Particle Light on the entire avatar but is listed as 2/1 lights in the avatar details https://vrchat.com/home/avatar/avtr_7c80a2a5-3473-421f-86ce-fdda8fa8eb3f Expected behavior: Lights should be listed as 1/1. Though I expect the 2/1 is likely due to the server-side(?) performance check adding both the light in the light prefab itself (Even though that prefab itself is not included in the hierarchy on the main avatar and is only used on the particle system) and the maximum lights in the particle system. I understand that this is a relatively niche usecase as most people would likely just use a a regular light, but having this singular light be part of a particle effect allows for some neat control of the light through manipulation of the particle. i.e. I use it as a way to add noise to the the size and intensity of the light which would be more complicated to implement using a normal light. Also, is it possible to update the performance stat calculation of SDK Test avatars to match the new behavior? It's still using the old behavior that only counts the prefab and not the particle light count itself. I need to upload the avatar to see the correct stats.

I've been noticing and increasing number of issues with physbones over the past couple of months. 1. Immobile used to work with Gravity, but now bones with gravity always shake violently while the avatar is moving quickly, completely ignoring immobile. Example: avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 avatar uses that to determine the up vector for the cat, walking around causes the cat to jump around, it never used to in older versions. 2. Physbones resting on or inside colliders vibrate, sometimes even to the point where they seem to struggle to stay inside inside-out colliders. This used to be stable with no vibration. In minor cases this can sometimes be mitigated with "physbones as spheres", but it never used to be necessary. Example: avtr_04a9d322-e228-4934-93b1-6e20b62cfded The boxing gloves on this avatar are long physbones with squish that are held back by inside-out colliders, they now vibrate violently at all times, they used to stay calmly in place.

Reproduction steps: Make AudioSource.pitch or volume changable from Radial Puppet using Motion Time from float parameter. Build & Test Open QM and change parameter. Result: Audio volume goes max at the frame that parameter changed. The volume returns when stop changing value. Expected: When pitch value changed, only pitch changes. When volume value changed, volume has sets exact value what that setted, not chattering. Note: It never happenes in Unity editor, Gesture Manager. Only in the client.

As part of simulating expressions such as smiling and frowning using just the visemes Selfie Expression drives the AA blendshape into the negatives. This looks very broken on all but the most basic human avatars. Selfie Expression should not drive AA or any of the shapes negative, remember that avatars can be creatures of all shapes, not just anime girls.

Currently, the shader type called Hidden that can be specified as a fallback shader is introduced on the following page as: > Hidden // (this will hide the mesh from view if the shader is blocked, useful for things like raymarching effects.) > https://creators.vrchat.com/avatars/shader-fallback-system/ However, if a mesh using this shader has an animation that sets the _Color alpha parameter to 1 , the mesh that should have been hidden by the fallback shader becomes visible. My guess is that this happens because the Hidden fallback shader is actually reusing an existing shader (such as Unlit/Color ) and simply sets the color alpha to 0 in order to hide the mesh. When an animation overrides the alpha value, the mesh ends up being rendered. As a solution, I would suggest either providing a dedicated Hidden shader, or adding a special “hidden” flag to the existing shaders so that polygons are not rendered at all.

If you do an animation on the "Action" layer as an emote, the foot positions are not baked properly. This only happens on index. It does not seem to happen on Oculus HMDs, Vive is untested. The theory is that it has to do with Index finger tracking breaking things. Left side is Oculus, right side is Index. https://gfycat.com/fearfuldizzygangesdolphin

Issue: Textures used in a material swap on particles seem to use an incorrect mipmap compared to textures used on the original material used by the particle system. VRChat Avatar showcasing the bug: https://vrchat.com/home/avatar/avtr_985cb361-cea2-4502-b406-72fe3b56acb1 The avatar contains a particle system that has toggles for 3 material swaps: The Red material is the default material the particle system was uploaded with The Blue material is the swap material and showcases the incorrect mipmap level The Blue(NoMipMap) material is the same as the Blue material but using a duplicate of the blue texture where the 'generate mipmaps' toggle in the texture import settings was unchecked. This material does not have the same bug as above. All textures used on materials for this particle system test were 512x512 and should look identical aside from color. Additional Notes: This seems to only apply to textures that are not in use on the avatar in it's initial state. i.e. adding an additional mesh/material to the avatar that is using the same texture used on the Blue material will result in the particle system using the correct mipmap level on the Blue swap. Reproduction Steps: Create a particle system Create an animation that swaps the material of the particle system with a material that uses a separate texture. Activate the particle system, observe the normal texture Swap materials being used by the particle system, observe the lower resolution texture Expected Behavior: The expected behavior is that the textures used in the particle system look as high quality as they need to, i.e. using the correct mipmap level for the distance they are at from the camera. Attachments Description: Attached is a video showcasing the bug.