Jump to content

Animation Persistence


Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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".

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by OptimoMaximo
  • Like 1
Link to comment
Share on other sites

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 by Christina Halpin
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Christina Halpin
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...