✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Animation Sequencing Timing Discrepancy - Request for Clarification and Support
Please note: I'm not asking for anything to be changed, quite the opposite. I'm just looking for information on how sequencing timing actually works, so I can work with it more precisely. SL has had a long-standing issue with animation sequencing. It’s been consistent over the years (I’ve been animating in SL since 2010 and aware of the problem since 2012) and shows up across all major animation systems used so far. (MLP, Perfect System, AvSitter). Types of animation sequences: In SL, animation sequences are used in two ways: Standalone animations arranged into a scene ('quasi' sequences) True sequences, where one long animation is split into smaller, timed parts. I'm specifically talking about the second type, the true sequences. Problem: Individually, the animations play for their intended duration, but when scripted into a sequence, there's a consistent mismatch in timing. • Animations are played for slightly less time than their actual length. • For example, an animation that is exactly 46 seconds long in playback wait time must be set to 44.5 seconds in the sequence to function correctly. • Only animations that are exactly 60 seconds in length appear unaffected. • It’s like sequencing scripts are using their own internal timing system. What It Is Not: Through extensive testing, I have ruled out several common variables: • The issue is not caused by the animation format (both .bvh and .anim are affected). • It is not related to framerate. I’ve tested it with random FPS between 10–30, but the problem exists regardless of FPS. • It does not depend on whether the animation is looped or non-looped. • The presence or absence of easing in/out settings does not affect it. • This issue isn’t limited to just one animation system. It has appeared in all systems that use animation sequencing: MLP and Perfect Sitter in the past, as well as AvSitter today. • Also, this behavior is consistent throughout different viewers. The Challenge: Because there is no documented formula for adjusting timing, animators are left to rely on trial and error to determine the correct values when sequencing animations. This becomes an enormous time sink, especially when working with complex animations. I tried calculating the needed adjustment as a percentage of the original animation length, but it didn’t hold up. It seems to follow some kind of logic that’s beyond my grasp. What I’m asking for: I’m not asking for any changes to how sequencing currently works on the grid or in the viewer; changing that would break existing content, and that’s not the goal. What I’d really appreciate is just some clarity - either: A clear explanation of why animation timing gets distorted during sequencing. A method - or even just a formula - animators can use to accurately adjust/recalculate animation lengths when sequencing. If that’s not possible, then some kind of tool or viewer feature that shows the “sequencing-effective” length of an animation would be a huge help. Just having access to this information would save hours of trial and error and make it much easier to create polished, smooth sequences. Why this is important With relatively little effort on your side, this could unlock new potential for immersive experiences across Second Life. Tool for fixing the timing issue could actually open up a whole new creative space. Properly timed animation sequences allow for smooth coordination with props, scene changes, and multi-character interactions. It would make advanced visual storytelling more accessible to animators and designers, and that would seriously enrich what's possible for interactive and immersive content in SL. I believe this is an opportunity for improvement that can happen relatively fast if LL provides information. Please, let's not miss it.
8
·

tracked

Replace Animation Overriders with a built-in solution in the viewer
Currently, all Animation Overriders ever written in the past 20 years (aye, 20) rely on scripts that require accurate information about what exactly the avatar is doing (i.e., moving, walking, idly standing around...), polled several times per second, in order to swiftly override a standard/default animation with a new one. This is a major source of lag, especially considering that current-generation AO HUDs additionally suffer from texture bloat, increasing the wearer's ARC, and so forth. Certain third-party viewers, which shall remain unnamed, have 'fixed' this issue by embedding the AO in the viewer itself — running fully client-side and not relying on any in-world scripts to do so. They don't have a HUD, so they're not sexy and flashy and cool-looking, but they can read from the same notecard format as LSL-based HUD AOs, and, strictly speaking, they're a great way of reducing lag. So long, of course, that people are aware that such an option exists and are familiar enough with how AOs are configured. Please consider overhauling the whole concept on the viewer side only, so that LSL-based HUD AOs become completely irrelevant. Think of an interface like you have for the Gestures — some kind of viewer-side pop-up window which can load the "standard" animation overrider notecard, and, well, do its magic. Exactly like certain TPVs already do. In fact, as you're considering to introduce RLV to the official SL Viewer... why not AOs as well? Note: There is not even the argument of what happens if an animation hasn't loaded — what will other users see? The answer is trivial: everybody already has the standard animations from 2002 pre-loaded. If someone's AO animations are slow in loading for some reason, your viewer will default to displaying that avatar using the default animations instead. In fact, that's exactly what happens today, when someone else's viewer, though that resident's AO, instructs our viewer to load animation X for avatar Y. If X is already in our cache, good, it will be shown. If not, it falls back to the default animation. There is absolutely nothing that you need to change on the overall code logic! And, of course, you don't even need to reinvent the wheel — just grab the code from the TPVs and use it. It's been there for eons — well before smilies! — and for eons we have had to struggle with LSL AOs and spread lag all over the place. Then: Promote it . It's useless to have a wonderful new technology which reduces animation overriding effectively to zero lag if no one knows about it. Grab the main suppliers of AOs in SL and announce the 'new' system, so that they also spread the news among their customers. They will only need to provide the notecard with the configuration and the animations inside. Note that the TPVs even allow multiple sets of AOs to be configured, and people can freely switch across them (it's even easier than locating that specific AO in your inventory... what was it called again?). This issue has just one drawback I can find: some AOs are rather sophisticated and go beyond what is usually offered on the 'standard' AO configuration notecard; their HUDs are especially designed to allow access to those nifty extras, and have great visual impact. So be it — soon (or so we hope) we'll have the Lua-scripted viewer, and such special effects are perfect for content creators to deploy their ultra-laggy HUDs. But to do that, there needs to be an embedded AO in the viewer itself first. And then, of course, the first thing to do is to get rid of those AOs on the 'free' avatars that come as standard when a new user registers... they should be the very first to use the 'new' system. Well, new for the SL Viewer, that is. Some other feedback/suggestions which are vaguely related to this one: * https://feedback.secondlife.com/feature-requests/p/animation-system-overhaul P.S.: The attachment is just a note on the history behind the Animation Overrider. It might be useful, amusing, or totally irrelevant, so feel free to ignore it 😅
1
Load More