Add Internal Animations for Bento and Attachment Bones
tracked
RohanaRaven Zerbino
Linden Lab never added an Internal always-running, default/background animation for Bento bones, like the ones that have existed for the classic body since the beginning of Second Life.
In practice, this means there is absolutely nothing that resets the rig to its default position when an animation stops. As a result, Bento bones remain frozen in the current frame of the animation that was stopped.
The situation is even worse with the system of attachment bones, which never had a simple reset mechanism at all.
Creators have been left to first figure out why bones appear in strange positions, and then to fix the problem manually, by creating low-priority neutral pose combined with always-running scripts that continuously replay background pose. This workaround is completely unnecessary and could be easily resolved by Linden Lab.
Unfortunately, both the need for such a fix and the workaround itself are not widely known, which is why we still see “stuck” Bento bones all over the grid.
Request:
Please finally complete the Bento project by adding an always-running, low-priority internal pose/animation for all Bento bones that keeps the rig in place. This task is long overdue, considering Bento was introduced years ago.
Also, in the same manner, add one simple, internal, always-running, background, low-priority default pose/animation that resets Attachment bones’ rotation and position.
I urge you to dedicate time to this request, which should be relatively quick to implement, as creators need this simple solution and shouldn’t face backlash from users due to the system’s lack of proper support.
If you need additional explanations and/or help on how/why to do this, please contact whoever brilliantly set up the internal animations in the first place.
Log In
Wyvern Dryke
I think this is an excellent proposition. LL needs to complete the Bento project. Please create very low priority, running animations to keep the Bento bones in please! Thank you.
Gael Streeter
Totally agree with this request even if it would come very late...
Boots Shamrock
Totally agree with Ro
hinaichigo Xaris
I’d like to point out that this is the expected behavior for non-skeletal Animesh.
Some people use Animesh to animate robots, buildings, trees, machines, octopuses, floating orbs, and other unusual organisms, devices, or structures.
Your proposed solution could cause problems for creators making non-humanoid creations.
RohanaRaven Zerbino
hinaichigo Xaris Internal animations do not affect Animesh. Animesh objects will only play animations that are explicitly added to them in some way.
As we speak, all avatars, regardless of shape, rig, or species, are under the influence of internal body animations. This has been consistent since the early days of Second Life and has not changed.
What I am asking is for internal avatar animations to be extended to added Bento bones, so there would be something to hold the bones in place instead of having to deal with stuck bones.
hinaichigo Xaris
RohanaRaven Zerbino I see, you’re right. But could this feature request affect non-humanoid avatars like dogs or horses?
RohanaRaven Zerbino
hinaichigo Xaris Internal body animations are playing on every avatar, no exception, but you don't see them, because they are low priority and over-ridden with AOs. This system exist for 20+ years. The same principle would be implemented for Bento bones.
hinaichigo Xaris
RohanaRaven Zerbino I see, then it is a "Yes" for me.
RohanaRaven Zerbino
hinaichigo Xaris Thank you for the opportunity to clarify things a bit further :)
Etheria Parrott
I'm sorry but this proposal has really worried me. I have created many many Bento animations at Priority 0. Can we have reassurance that if internal animations were to happen, they would all be at Priority -0 (that's a minus)?
Bloodsong Termagant
OMG YES!
RohanaRaven Zerbino
Etheria Parrott This is a practical confirmation of the kind of problems created when there is no proper system solution and the job is left unfinished. Creators are left on their own to individually determine the solutions they consider best. When deciding on animation priorities, creators need to consider the bigger picture and how their animations might interact with others in-world, rather than focusing solely on whether they need higher priority for their own creations.
I hope you haven’t advised other creators to take the same path, and I also hope that any future system solution if one ever comes will integrate smoothly with existing creations. Thank you for taking the time to comment, it is extremely important to see the full picture of the problem.
Etheria Parrott
RohanaRaven Zerbino Yes I have advised other creators to make Priority zero animations for bento bones in my role as Avastar support. We have always advised to use the lowest priority needed. For instance, to set a hand pose other than the spread fingers would be P0, then another creator will want to make a moving hand animation so would need P1 and another creator would need to freeze the hands such as a bag hold and would choose a higher one. The proposal would break animation content unless all background animations made by LL are P-1 (Priority minus 1). My tails are all P0, as are my wings. Looking at what the existing internal animations are: P4 for a sit and P3 for a female walk, I am worried that bento bones could follow a similar pattern if the animators chosen by LL don't understand the problem.
On another note, please promise to use only Rotation keyframes. Too many human animators are using Location with Rotation keyframes thus borking those of different sizes.
RohanaRaven Zerbino
Etheria Parrott While I understand that in certain lines of work your approach is correct, please note that in my line of work it’s completely useless. My animations are full-body with Bento fingers and are designed to override AOs, while AOs themselves must override internal animations. At one point, AO creators raised their priority from 3 to 4, so furniture animations had to move to priority 5 to maintain proper functionality and layering. In a way, you could say I’m already using the lowest priority necessary.
As for the keyframing part - please don’t. Certain bones, such as IKs and the COG, must be keyframed with locations; otherwise, they’re simply useless. And just to clarify, using location keyframes (assuming you never export them with bone translations) has absolutely nothing to do with “borking avatars of different sizes.” Unless, of course, you meant that exporting with bone locations breaks the avatar? My animations have been used grid-wide by avatars of all sizes (even tinies) for 15 years, and aside from the usual issues caused by different proportions (not size!) leading to expected minor imperfections, they show zero “borking” whatsoever.
After so many years and countless animations, I’ve found that theory and documentation often sound neat on paper, but the grid tends to reveal what truly holds up in practice.
For what I’m asking, animators aren’t even needed. A full set of animations like those used for the body would actually be the wrong approach, especially considering the wild west situation with Bento heads. All that’s needed is a single animation to zero out all the bones, that’s it. If Linden Lab has a way to make it a priority of -1, even better.
SL Feedback
marked this post as
tracked
SL Feedback
Hello, and thank you for your detailed feature request regarding the addition of internal animations for Bento and attachment bones. This issue has indeed been brought up before by another resident, and we have found a duplicate post in Second Life's previous bug tracking system (BUG-11252). We are merging your comments with the existing report to ensure it gets the attention it deserves. While we cannot provide an estimate on when this might be implemented, please know that it is now being tracked. We appreciate your input and hope you continue to share your ideas to help improve Second Life. Thank you!
RohanaRaven Zerbino
SL Feedback Merging this request with the “previous bug tracking system” clearly means Jira, which you left behind in early 2024, if I’m not mistaken.
So you’ve known about this issue for years, yet here we are: no grid-wide fix, no system solution, nothing, for something so simple and so needed for creators.
Wow. Just… wow.
steph Arnott
RohanaRaven Zerbino, it is not simple.
RohanaRaven Zerbino
steph Arnott Care to explain so we could understand and/or even discuss it?