[BUG-227435] Animation offset behavior has changed (BVH)

[sl-service-account]

What just happened?

Animations are jumping up and down as they are changed in vehicles where they didn't do that before.

What were you doing when it happened?

Using vehicles I created that have a variety of animations with offsets in them.

What were you expecting to happen instead?

The avatar shouldn't jump up to the llSitTarget when switching between animations with offsets.

Other information

When creating vehicle animations, it is very common to create the animation with a negative Z offset so that the avatar drops down when the animation is played. This is necessary to prevent the avatar bounding box from hitting the ground and potentially raising the vehicle up and causing it to float.

In a BVH animation, this is represented by the first frame having a Z offset, and all subsequent frames having a lower Z offset. This first frame is special and NOT considered part of the animation, but a reference frame so that the BVH to anim conversion knows how to offset the avatar, as well as to determine which joints are animated and which ones are not.

In the past, I could switch at will between these offset animations in my vehicles, and they all stayed offset (typically 1M down from llSitTarget) without any problems. This keeps the avatar bounding box well above ground where it won't make the vehicle float.

Now, the Ease IN transition is being tweened from the llSitTarget that is up in the air, instead of the animation's offset position where it should be tweened from. This is causing the avatar to jump up and down as the animation is changed. (See example vid)

A sort-of work-around is to use an Ease-IN of 0, but that looks terrible, and doesn't fix past animations and products.

Attachments

• Offset Animation Jump.mp4 2019-08-01 20:33:09

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-227435 | | Summary | Animation offset behavior has changed (BVH) | | Type | Bug | | Priority | Unset | | Status | Needs More Info | | Resolution | Unresolved | | Reporter | Phate Shepherd (phate.shepherd) | | Created at | 2019-08-01T23:15:26Z | | Updated at | 2019-08-05T17:31:25Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2019-08-01T18:46:25.489-0500', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': "Animations are jumping up and down where they didn't before.", 'What were you doing when it happened?': 'Using vehicles I created that have a variety of animations with offsets in them.', 'What were you expecting to happen instead?': "The avatar shouldn't jump up to the llSitTarget when switching between animations with offsets.", } ```

[sl-service-account]

Lucia Nightfire commented at 2019-08-01T23:46:25Z, updated at 2019-08-01T23:47:01Z

AFAIK, this has always been the case.

You can't blame interpolation on the sit target when an offset animation using ease-out is stopped.

You can't blame interpolation on the sit target when an offset animation using an ease-in is started.

The same effect will happen starting or stopping without sitting because you're using an offset animation that uses easing.

Why not simply use a zero_vector sittarget and upon sit, change the sitter's local position/rotation to the desired location in the vehicle with llSLPP* and use a non-offset animation instead?

[sl-service-account]

Phate Shepherd commented at 2019-08-02T00:11:25Z, updated at 2019-08-02T00:15:52Z

Then why have I never seen this behavior until recently? I have built many vehicle products, and I would not have let them leave the door with the jumping up on changing animations.

I am not sure sure how the zero-vector sit target would help. With non-offset animations, the bounding box will be wherever the avatar is linked to, even with llSLPP, right? And if their bounding box extends below ground, it will raise the vehicle up.

That was the whole reason to use the negative offset animations. The bounding box stays up in the air at the sit target, and the avi moves down into place at ground level.

[sl-service-account]

Phate Shepherd commented at 2019-08-02T00:15:15Z

BTW, what I am saying is that in the past, the avatars current position was used as the ease-in starting point for tweening, now it appears to be the sit target.

[sl-service-account]

Lucia Nightfire commented at 2019-08-02T07:10:00Z

"BTW, what I am saying is that in the past, the avatars current position was used as the ease-in starting point for tweening, now it appears to be the sit target."

What happens when you sit on a prim, change you local position either by edit link mode or by SLPP* and then play your animation? You should still see easing from that location. A sit target position shouldn't matter. There should be no difference between a sat user's position created by sit target or by SLPP*.

I still don't know why you can't reference a sitter's size and make the bottom of that height match the bottom of your wagon's wheels so the overall bounding box is evenly on the ground.

Countering a high vertical sit target with an offset animation is redundant.

[sl-service-account]

Phate Shepherd commented at 2019-08-02T16:40:01Z

For typical vehicles, no-offset animations are fine. There are no issues.

The problem is with vehicles where you sit close to the ground. Think of go-karts, low-rider bikes, etc. Imagine an animation where you are sitting straight up, with your legs straight forward like you are sitting on a go-kart. The avatar bounding box extends far below your butt. If your vehicle has you sitting close to the ground, that bounding box sticks down well below the go-kart, causing the whole vehicle to rise up in the air so that your bounding box stays above ground. This has been an issue as long as I have been on SL and the workaround has been to offset the animation downward (typically 1M) so that the sit target AND the bounding box are 1 meter up in the air, and the avatar animation puts it down 1 meter. Avatar bounding boxes do not move with the animation, they always stay at the sit target. Avatars are not phantom when sitting on vehicles, nor can they made to be phantom.

This is why I did the tutorial on creating offset animations for AnyPose to help the bike builder community fix the problem of their low-rider bikes hovering off the ground.

Now, to complicate matters, child avatars and other micro avatars shrink the avatar, but the bounding box is still adult size. This would normally cause them to float way above ground when just walking around if it weren't for the hover height adjustment. So, if I want to allow a child avatar to pull a wagon, or do pretty much anything with a vehicle, they have to be offset animations to get their oversized bounding box up in the air so that they can appear to be walking at ground level (or to avoid the vehicle floating half a meter or more above ground.)

I will test moving the avi via llSLPP or edit mode again, but I am nearly positive it will have no effect as the vehicle I am currently testing with, I used AVSitter for avatar positioning, which uses llSLPP to move the avi, and the bounding box moves when you adjust avi position.

[sl-service-account]

Phate Shepherd commented at 2019-08-02T23:32:01Z

I am narrowing down the issue further. It appears to be a change in how animations are played that started out as 2 frame BVH files. 2 frame animations are really single frame animations. The first is the reference frame, and the second is where you want the avatar and joints positioned relative to the first frame.

I have found a work-around by adding padding frames to the end of these 2 frame animations, but that doesn't fix older products that use offset 2 frame animations.

I know this issue is esoteric... but there has been a change in behavior of the animation playback.

[sl-service-account]

Kyle Linden commented at 2019-08-05T17:31:25Z

Hi Phate,

Can you provide some sample content that we can test against older viewers and/or older simulators?

Please press the Info Provided button when you update this report.

Thanks!