Animation Persistence

[Christina Halpin]

Everyone here seems to agree there should be good information about animation persistence.

There isn't.

The best way to get that information is a group discussion. One person can't do it.

I started a thread on persistence of jaw-jutting. I should have made the topic more general, hence this new thread. You can read that thread.

 I kind of have to argue that situation now isn't good, please don't blame me for that.

I will start with something no one mentioned.

[Christina Halpin]

As near as I can tell, animation persistence is client side.

So, if you as user are suffering from animation persistence, you can click on Avatar Health/Undeform Avatar and the problem will seem to go away. But it's disappearing on your screen, not other people's.

If you tp somewhere else, you seem to have the animation persistence, but no one else sees it because they get up-to-date information. You are the only one seeing a problem, and that problem can be solved with undeform Avatar.

This is very important to know for testing. If you are animator trying to write an undeform animation, you have to make sure it works on nearby avatars. You also have to realize that the problem isn't correcting the deformation, it's telling SL to update the client side. (I had a animation that set the jaw position to normal but moved nothing, and it worked for me but not others.)

The Second Life webpage on Avatar Deformations seems unaware of this. (That depends on what they mean by deformation.)

I am painfully aware of my limitations, and if I am making some mistake here, I want to know. I already touted the necessity of group discussion.

[Lucia Nightfire]

See https://jira.secondlife.com/browse/BUG-225527 to allow resetting the skeleton to be seen by others.

[Christina Halpin]

Thanks! I could not get this to work. I know of two reset skeletons, one under Avatar and one starting from a right click on avatar. Neither worked for me. I tried different combinations of Firestorm and Second Life with no success, and I tried two different animations that had persistence, one for the jaw with dislocation and one for the eyebrows that was just the "default" for Avastar.

[Christina Halpin]

My pose with eyebrow persistence could be fixed by not including location when saving.

That didn't work for jaw jut because the things I had to do to make that work as an animation always got persistence.

In theory, that could be fixed by running an animation to move things back to normal. If you can do that without creating persistence in your new animation, great. If the new animation creates persistence, then what do you want to persist? The "default" body position in Avastar does not correspond to my head, it leaves my eyebrows raised. The "neutral" position works for me, but OptimoMaximo suggests heads will be different.

Fortunately, the correct return values are already sitting in the Linden computer, it just has to be provoked to updating client side. In my testing, animations that create persistence also eliminate persistence.. For example, a pose that extends my little finger eliminates jaw jut.

[OptimoMaximo]

1 hour ago, Christina Halpin said:

Fortunately, the correct return values are already sitting in the Linden computer, it just has to be provoked to updating client side. In my testing, animations that create persistence also eliminate persistence.. For example, a pose that extends my little finger eliminates jaw jut.

Ouch! What you're describing is bad practice, because it basically means that you're exporting ALL joints positions when doing you little finger extension, including what you did not animate! So why is it bad? Because you're dumping unnecessary data into a file that would be way fewer bytes in size. Animations have a limit of either 60 seconds length, or 250kb, whichever is hit first. You're wasting resources, and slowing down both viewer loading and server streaming, because of their bigger sizes. Not specifically the case of these really short animations, but still... Everything adds up to the pile when you think of a crowded place.

[Christina Halpin]

15 hours ago, OptimoMaximo said:

Ouch! What you're describing is bad practice, because it basically means that you're exporting ALL joints positions when doing you little finger extension, including what you did not animate! So why is it bad? Because you're dumping unnecessary data into a file that would be way fewer bytes in size. Animations have a limit of either 60 seconds length, or 250kb, whichever is hit first. You're wasting resources, and slowing down both viewer loading and server streaming, because of their bigger sizes. Not specifically the case of these really short animations, but still... Everything adds up to the pile when you think of a crowded place.

That undeforming pose of mine was 5K I think a pose from frame 1 to frame 1 counts as zero seconds. But it was unacceptable, because it moved my avatar to a neutral position  (arms out) until I manually stopped it. An undeformer should be invisible except to correct the problem of animation persistence.

I still  want to make the point that the goal isn't exactly to move the offending bone back into position, because it already is in the Linden computer; the goal is to update the position of the bone on the client side. I don't know if that information is useful.

If the only way to update, say, the jaw, is with a program that moves only the jaw in a way that will persist, then the undeformer can target just the jaw (maybe?). But we still have the problem of finding neutral for the jaw.

[Christina Halpin]

I may be overthinking this, but . .. . there is an issue of which bones are vulnerable to persistence.

When I got persistence with the hip bone, I thought any bone. But, as RohanaRaven suggested, I could not get it with the tongue. (How much did the Tongue lobby have to donate to get that?)

I can get persistence in the eyebrow without manually unlocking it, if I have dislocated the jaw.

[Christina Halpin]

I have a question. Why doesn't Linden fix this problem?

Too difficult to program? Seems unlikely. RohanRaven suggested that the tongue is special, and I could not get any persistence on the tongue. So, it seems there is already code for this. To correct the problem for eyebrows is making a loop? Fixing it for everything is the same loop.

Too much client-side computer time? Seems unlikely. Wouldn't a correct at the end be like adding an additional frame to an animation?

Perhaps it would create problems like arm-flapping. The current Undeform option creates armflapping. Perhaps the current reset of tongue also has flapping, but it's inside the mouth so no one cares. To me, this would be a very good reason for not doing it.

The persistence is a "feature" somewhere else? Because it is so easily undone, for example by logging in, I rate this as unlikely too.

[Jenna Huntsman]

3 minutes ago, Christina Halpin said:

I have a question. Why doesn't Linden fix this problem?

Too difficult to program? Seems unlikely. RohanRaven suggested that the tongue is special, and I could not get any persistence on the tongue. So, it seems there is already code for this. To correct the problem for eyebrows is making a loop? Fixing it for everything is the same loop.

Too much client-side computer time? Seems unlikely. Wouldn't a correct at the end be like adding an additional frame to an animation?

Perhaps it would create problems like arm-flapping. The current Undeform option creates armflapping. Perhaps the current reset of tongue also has flapping, but it's inside the mouth so no one cares. To me, this would be a very good reason for not doing it.

The persistence is a "feature" somewhere else? Because it is so easily undone, for example by logging in, I rate this as unlikely too.

The simple answer is that it's a bug that was introduced by Project Bento which has been around long enough to have become a "feature", so there's content that relies on bones not being reset when an animation stops. See many items marked as deformers, for one example.

To fix it would likely break other content, so it's not an uncontroversial change to fix this bug, although as of late LL are being more strict about content that is leveraging these "undocumented features".

[OptimoMaximo]

On 1/20/2023 at 4:11 PM, Christina Halpin said:

That undeforming pose of mine was 5K I think a pose from frame 1 to frame 1 counts as zero seconds. But it was unacceptable, because it moved my avatar to a neutral position  (arms out) until I manually stopped it. An undeformer should be invisible except to correct the problem of animation persistence.

That's how undeformers work, actually. You just exported it as looping animation, while you might have got the same result by having that same animation, not looping, ease in and out values to 0. Undeformers are either full body, to avoid mistakes, or aimed at your own issue and run when detaching the attachment that starts a problematic animation

 

On 1/20/2023 at 4:11 PM, Christina Halpin said:

I still  want to make the point that the goal isn't exactly to move the offending bone back into position, because it already is in the Linden computer; the goal is to update the position of the bone on the client side. I don't know if that information is useful.

OK let's make this bit of information more clearly known and stated: on the servers, there is no skeleton, pose or animation information. The Skeleton definitions used when rezzing, changing shapes, running animations all reside within the viewer's installation folders.

All updates are sent from client to server, and the server then distributes those updates to all connected viewers in view range. Those updates are then interpreted through those definition files and finally shown on screen.

Now, the problem with animated positions is that these are absolute positions from the avatar root. So if the user has a shape that has the jaw joint say 10 cm higher and 3cm backwards than the default, imposing the default position via animation would not account for the shape, placing the jaw 10cm lower and 3cm forwards in comparison to the user's shape.

[Christina Halpin]

4 hours ago, Jenna Huntsman said:

The simple answer is that it's a bug that was introduced by Project Bento which has been around long enough to have become a "feature", so there's content that relies on bones not being reset when an animation stops. See many items marked as deformers, for one example.

To fix it would likely break other content, so it's not an uncontroversial change to fix this bug, although as of late LL are being more strict about content that is leveraging these "undocumented features".

If I created a deforming animation, say, to have a very long pinky finger . . . why wouldn't I keep running the animation until I didn't want the long pinky?

If I want my deformation to continue  after stopping, I run into a fragility problem. People popping into the sim won't see me with a long pinky, and if I move to another sim I will  still see the long pinky but no one else will. And the effect disappears on log in.

I understand the problem that Linden Lab has to worry about any change having undesirable effects. I am wondering if this could be a situation where no one is relying on persistence.

[OptimoMaximo]

1 hour ago, Christina Halpin said:

If I created a deforming animation, say, to have a very long pinky finger . . . why wouldn't I keep running the animation until I didn't want the long pinky?

If I want my deformation to continue  after stopping, I run into a fragility problem. People popping into the sim won't see me with a long pinky, and if I move to another sim I will  still see the long pinky but no one else will. And the effect disappears on log in.

That is a case for a custom joint position MESH to wear and achieve a persistent deformation, which would respect the sliders influences and would be visible to anyone in range, newcomers included. And stops and resets automatically on detach from avatar

Edited January 22, 2023 by OptimoMaximo

[Christina Halpin]

When I click on Full Face AO on my head, that eliminates persistence from one of my poses. That sounds good . . . but it's a real problem for testing, right? To test for persistence, I have to avoid any correcting effects from other running animations. In other words, with Full Face AO on, I cannot do a good test for persistence.

Meanwhile, I need to have those animations on to make sure my pose is stronger than them. So I have to have Full Face AO on for that test.

We can discuss specifics, but there is a general problem: If we don't know the details of when persistence might be created, and if we can't reliably test for it, that's not good. And it's another reason to just get rid of it.

(Specifics. I am using a year-old CATWA HDPro. Their webpage says that (or the current version) runs at Priority 1, but mine can break a Priority 5 pose, so something in myFull Face AO must be priority 5.)

 

Edited January 22, 2023 by Christina Halpin

[Christina Halpin]

On 1/21/2023 at 7:05 PM, OptimoMaximo said:

That is a case for a custom joint position MESH to wear and achieve a persistent deformation, which would respect the sliders influences and would be visible to anyone in range, newcomers included. And stops and resets automatically on detach from avatar

which makes the point -- if I wanted a deformation that persisted past the animation, there are probably better ways to do it.

[Christina Halpin]

On 1/21/2023 at 12:21 PM, OptimoMaximo said:

That's how undeformers work, actually. You just exported it as looping animation, while you might have got the same result by having that same animation, not looping, ease in and out values to 0. Undeformers are either full body, to avoid mistakes, or aimed at your own issue and run when detaching the attachment that starts a problematic animation

The undeformer I made, which seems to work so far, is a single frame, non-looping.

I targeted it to my all of my face. I am guessing that the work I need to do to get persistence with my hip or finger is rare and it will will be obvious I need more than just my simple undeformer. I don't get arm flapping or jump-to-standing, of course; If there is an analogous thing for the face, I haven't seen it yet.

As noted in the other thread, I used the neutral pose in Avastar, not the default, which might be specific to my CATWA HDPro head.

Edited January 23, 2023 by Christina Halpin

[Christina Halpin]

After an animation is over, I would like to return them to how they entered the world. Call that Entry Shape.

In Avastar, I can return them to "Default Shape" or "Neutral Shape". Unfortunately, neither of those is quite the same as Entry Shape.

I think I need a blender file corresponding to Entry Shape. Is that possible?

(For me, "Default Shape" and "Neutral Shape" get both the lip pursing and shoulder breadth wrong; 'Default Shape" gets the eyebrow height wrong and "Neutral Shape" has a different jaw jut.)

[Christina Halpin]

Thanks to everyone for the discussion. It helped me. I am more on top of the problem now. We are done?

In case anyone finds this page with a search engine, here is my best guess -- time-dated with no guarantee. I suspect there is no consensus on any of this, this is a result of my own explorations, including asking people and discussing on this forum. I would be glad to hear corrections and more information, as I still have to deal with this problem.

IF YOU ARE SUFFERING FROM ANIMATION PERSISTENCE

The effects are often subtle and you won't notice. If you do . . .

Log off and then back on.

Alternatively, if you can find “reset skeleton” or “undeform”, this will (probably, mostly) eliminate the effects for you, but only on you – everyone else currently at the sim will see you as deformed. If you teleport to a different sim (not to a different location in the same sim), you will be returned to normal for other people there and you can even return to the same sim and be seen as normal. So the two can be combined to avoid logging off and on.

IF YOU ARE AN ANIMATOR

You might want to know when you have to worry about persistence. As far as I know, one sign is saving location (in Avastar). If you have, for example, detached one bone from another, the things you do have this work as an animation unfortunately are likely to cause effects to persist.

Another danger sign is animating (or perhaps just saving) things in the face.

Using priority 6 is another danger sign. My AO on my head eliminates much persistence that is Priority 5 or below. Of course, the same things that eliminate persistence have good potential to break your animation.

You might want to test for persistence. That probably means turning off the things on yourself that might break persistence. These are the same things you have to have on to make sure your Priority 5 or less animation is not broken by someone's AO. So, unfortunately, whatever you wear to test that your animation works, you should take it off to test for persistence.

The easiest way to avoid all large effects and most small ones is to include a neutral or default animation in your ease-out. A single frame should be enough, and that will be too fast for SL to show, so it should be invisible (instead of making some unwanted jerk). The persistence effects are client-side, so the single frame is apparently enough to trigger SL to update all clients.

By definition, the form someone has when they log in is the correct one, but I have not found that yet. The persisting effects from Avastar's neutral or default animation tend to be few and small.

LINDEN LABS

Animation persistence should not exist. The effect is unexpected and undesired – the person just turned the animation off. Normally, one person's bug is another person's feature, but this effect is too fragile to be of positive use.

I do not know the mechanics for how much computer time or programming effort that would take. So this is not my decision to make. But . . .

There is no animation persistence for the tongue or COG bone. If they have their own routine to prevent this this, you might simply everything else to this list. Or at least add the face bones to this routine (and perhaps shoulder breadth). An animator creating persistence in the hip is likely to notice the problem and deal with it, if there are time issues with turning off the effects for everyone bone.

Reset Skeleton is dangerous and should be eliminated. The problem is, the person might think they have fixed the problem (they look fine on their screen) but they have not (they are deformed on everyone else's). This change is not needed if you implement your intended change such that clicks on these update everyone else's computer too.

I note two insidious, potential problems. First, head-makers might get a lot of complaints if their head is deformed by persistence. It's not their fault, but they still might have to deal with it. So they might inrease the Priority of the things on their head that eliminate persistence. This also probably breaks any attempts to animate they heads, which animators can currently avoid by using Priority 6.

That might put pressure on the head makers to break Priority 6 animations, which means animators won't be able to animate the face unless they use Priority 7, which you might have to add once a head-maker starts breaking Priority 6 animations.

Second. We can solve this whole problem, mostly, if the person writing the animation software (such as Avastar) automatically adds the correct default position to their animation and has them play on ease out. If they do . . . won't that be a time-consuming?

And if this is a problem, you want to fix it before the programmers add this fix, not be trying to convince them to take it out.

I do not want to say this is the end of the problems created by animation persistence. Other problems are probably too hard to solve, but I will mention them.

You might want to have a page – updated as needed? – explaining to animators what is needed to avoid this problem. You might want to fill in the holes I have left – what exactly can cause this problem and what cannot. You can talk about different Heads, different settings on the heads, different bodies, and different animation-creation programs.

My very old non-mesh avatar regularly experiences eye pop-out as animation persistence, I think from any attempt to animate the face. You might want to make make sure that beginners are not given a body that will experience this problem. (If they will, you might want to explain to them how to solve the problem; my explanation is above.)

 

Namaste

Edited February 15, 2023 by Christina Halpin

[Love Zhaoying]

58 minutes ago, Christina Halpin said:

My very old non-mesh avatar regularly experiences eye pop-out

That sounds painful and scary!