Unsupported bones permanently affect subsequent animations
tracked
Froukje Hoorenbeek
The animation uploader currently allows animations to include additional Bento body bones that are not part of the supported body animation skeleton for standard human avatars, such as Spine1–Spine4.
Because these bones are not reset by Second Life's default animation system, they remain in their last animated state after the animation ends.
As a result, subsequent, perfectly valid animations can appear broken, even though the problem actually originates from a previous animation. This makes the issue extremely difficult to diagnose and causes creators of correct animations to receive support requests for problems they did not create.
Because the animation uploader accepts these unsupported body animation bones without any warning, creators may not even realize they are exporting animation data that can affect subsequent animations.
This is not just an issue for individual animations. Full-perm animation packs are widely reused by furniture creators throughout Second Life. A single incompatible animation pack can therefore affect a large number of products created by different people, while the resulting support requests are often directed at the wrong creator.
Possible solutions
- Reject unsupported body animation bones during upload.
- Warn creators when unsupported body animation bones are detected during upload.
- Automatically reset unsupported body animation bones when an animation ends.
Addressing this would significantly improve compatibility between animations from different creators.
Log In
Froukje Hoorenbeek
Photo Viewer
View photos in a modal
Wulfie Reanimator
This problem where you have to reset your skeleton after a bento animation plays happens because of a quirk: When the last animation on a bone is stopped, the bone stays in place. It's not because of anything unsupported.
As a fix, some scripts (like in mesh bodies) play a low-priority animation to keep things like hands in a neutral pose. TPVs like Firestorm can also do this.
Froukje Hoorenbeek
Wulfie Reanimator In a system like AVsitter, this would only work if you deliberately inserted a neutral reset animation between animations. In practice, that would mean inserting one after every animation that animates those body bones, or before every subsequent animation that does not.
I experimented with this approach. The reset animation is visible to the user. It breaks the flow of the interaction, so it isn't a practical solution for seamless furniture animations.
RohanaRaven Zerbino
Wulfie Reanimator This issue is specifically about Avatar Body Skeleton animations. Not Bento, not Animesh, not Custom Avatars.
The Avatar Body Animation Skeleton has never changed and never received additional bones. It still relies on the SL default/inbuilt body animations for resets - something that Bento additions are missing, hence the need for workarounds.
When additional bones are used in Avatar Body Skeleton animations, they are not covered by that reset system. They stay in their last position and affect animations played afterward. Therefore, they are not supported for this particular usage.
RohanaRaven Zerbino
Froukje has covered the main issue very well. I would just like to add one additional point:
The animation upload system is not used only for the SL Avatar Skeleton. There are many Animesh and Custom Avatar creators who may rely on bones that are not supported by the SL Avatar Skeleton, as their creations are custom and standalone systems.
Therefore, I would like to propose a dual animation upload system:
• one that validates compatibility with the SL Avatar Skeleton.
• one that provides the freedom Animesh and Custom Avatar creators need.
As animation terminology is often blurry and some terms are used interchangeably, I just want to make one clarification:
SL Avatar Skeleton refers to the combination of SL Body Skeleton + SL Bento Additions.
Dan Linden
updated the status to
tracked
Dan Linden
Thank you for the report, Froukje!
Issue tracked at https://github.com/secondlife/viewer/issues/5983. We have no estimate when it may be implemented. Please see future updates here.