Pose Studio: while active, other Slipstream viewers stop seeing volume-bone animations (even with no bones posed) #839

New issue

Closed

opened 2026-10-18 05:31:24 +00:00 by sky_line · 3 comments

sky_line commented

2026-10-18 05:31:24 +00:00

Owner

While Pose Studio is active, other people stop seeing some of your animations, apparently those that move volume bones (collision volumes, e.g. butt / belly / chest / tail-style volume animations). It happens even with no bones posed: just having Pose Studio open / active is enough.

Likely cause (from reading the code, not yet confirmed)

Pose Studio is built on the poser's posing motion (fsposingmotion.cpp / fsposeranimator.cpp). FSPosingMotion::onInitialize adds a joint state for every character joint and every collision volume (fsposingmotion.cpp:45-66, addJointState with POSER_JOINT_STATE). While the motion is active, those joint states take part in blending for all of them, posed or not. If an unposed joint's state still carries rotation / position / scale at the motion's priority, it overrides lower-priority animations on those joints. Volume-bone animations are typically low priority, so they lose.

Which "other clients"?

Two different paths to check:

Other Slipstream viewers receive the shared pose over the bridge (slposesync.cpp) and run a posing motion for your avatar locally. If that motion is applied whenever sharing is on, even with nothing posed, it would hide your volume animations in their view.
Non-Slipstream viewers (Firestorm, LL) only see server-side animations. If they also lose your volume animations, something is being sent to the sim (an animation start / stop, a pose-related state), not just the local motion.
Establish which viewers are affected first.

Expected

With nothing posed, Pose Studio should not affect any joint. Only bones the user actually posed should be overridden, locally and in the shared pose, and only those joints should have a joint state or priority in the posing motion (or unposed joints should carry no weight). Collision volumes should only be touched if the user poses them.

Repro

Wear something with volume-bone animations (or play an animation that animates collision volumes), have another person watch, open Pose Studio without posing anything, and compare what they see with Pose Studio open vs closed.

While Pose Studio is active, other people stop seeing some of your animations, apparently those that move **volume bones** (collision volumes, e.g. butt / belly / chest / tail-style volume animations). It happens even with **no bones posed**: just having Pose Studio open / active is enough. ### Likely cause (from reading the code, not yet confirmed) Pose Studio is built on the poser's posing motion (`fsposingmotion.cpp` / `fsposeranimator.cpp`). `FSPosingMotion::onInitialize` adds a joint state for **every** character joint **and every collision volume** (`fsposingmotion.cpp:45-66`, `addJointState` with `POSER_JOINT_STATE`). While the motion is active, those joint states take part in blending for all of them, posed or not. If an unposed joint's state still carries rotation / position / scale at the motion's priority, it overrides lower-priority animations on those joints. Volume-bone animations are typically low priority, so they lose. ### Which "other clients"? Two different paths to check: - **Other Slipstream viewers** receive the shared pose over the bridge (`slposesync.cpp`) and run a posing motion for your avatar locally. If that motion is applied whenever sharing is on, even with nothing posed, it would hide your volume animations in their view. - **Non-Slipstream viewers** (Firestorm, LL) only see server-side animations. If they also lose your volume animations, something is being sent to the sim (an animation start / stop, a pose-related state), not just the local motion. Establish which viewers are affected first. ### Expected With nothing posed, Pose Studio should not affect any joint. Only bones the user actually posed should be overridden, locally and in the shared pose, and only those joints should have a joint state or priority in the posing motion (or unposed joints should carry no weight). Collision volumes should only be touched if the user poses them. ### Repro Wear something with volume-bone animations (or play an animation that animates collision volumes), have another person watch, open Pose Studio without posing anything, and compare what they see with Pose Studio open vs closed.

sky_line added the

labels

2026-10-18 05:31:24 +00:00

sky_line added this to the Slipstream project

2026-10-18 05:31:24 +00:00

sky_line commented

2026-10-18 05:33:59 +00:00

Author

Owner

Narrowed: only other Slipstream viewers are affected. Pose Studio shares poses only over the bridge's LSL messages to other Slipstream instances (slposesync.cpp); nothing reaches the sim's animation state, so Firestorm and LL viewers can't be affected.

So the fault is on the receiving side, or in what's sent. With Pose Studio active, a watching Slipstream viewer runs a posing motion for the poser's avatar from the shared pose, and that motion overrides the avatar's volume-bone animations even when nothing is posed. Check:

what the sharer sends while nothing is posed (an all-joints / all-volumes pose, or "no pose");
how the receiver applies it: a posing motion with a joint state for every joint and collision volume (fsposingmotion.cpp:45-66) at a priority that beats the avatar's normal animations.

The fix: the receiver only overrides joints actually posed in the shared data (and nothing at all for an empty pose), and the sender doesn't share unposed joints.

Narrowed: only other **Slipstream** viewers are affected. Pose Studio shares poses only over the bridge's LSL messages to other Slipstream instances (`slposesync.cpp`); nothing reaches the sim's animation state, so Firestorm and LL viewers can't be affected. So the fault is on the **receiving** side, or in what's sent. With Pose Studio active, a watching Slipstream viewer runs a posing motion for the poser's avatar from the shared pose, and that motion overrides the avatar's volume-bone animations even when nothing is posed. Check: 1. what the sharer sends while nothing is posed (an all-joints / all-volumes pose, or "no pose"); 2. how the receiver applies it: a posing motion with a joint state for every joint and collision volume (`fsposingmotion.cpp:45-66`) at a priority that beats the avatar's normal animations. The fix: the receiver only overrides joints actually posed in the shared data (and nothing at all for an empty pose), and the sender doesn't share unposed joints.

sky_line changed title from ~~Pose Studio: while active, other viewers stop seeing volume-bone animations (even with no bones posed)~~ to Pose Studio: while active, other Slipstream viewers stop seeing volume-bone animations (even with no bones posed)

2026-10-18 05:34:00 +00:00

sky_line commented

2026-10-18 05:34:45 +00:00

Author

Owner

Also: the Pose Studio user still sees their own volume-bone animations fine; only other Slipstream viewers watching them are affected. So the sharer's own local posing motion is not the problem. Look at what is shared over the bridge (slposesync.cpp) and how receivers apply it to the remote avatar (the receiving side's posing motion / joint priorities), not the sharer's local motion.

Also: the Pose Studio user **still sees their own volume-bone animations fine**; only *other* Slipstream viewers watching them are affected. So the sharer's own local posing motion is not the problem. Look at what is shared over the bridge (`slposesync.cpp`) and how receivers apply it to the remote avatar (the receiving side's posing motion / joint priorities), not the sharer's local motion.

sky_line referenced this issue from a commit

2026-10-22 19:32:55 +00:00

#839 Pose sharing: release unposed bones and collision volumes on receiving viewers

sky_line added

and removed

labels

2026-10-24 09:11:03 +00:00

sky_line commented