uploader double-replaces BVH animation reference frame

[Quarrel Kukulcan]

"The first frame of a BVH file isn't displayed. It's used to determine which joints the animation controls."

That's from the wiki, so no surprise there. In what I assume is an attempt to preserve the animation length, SL will replace the first frame with a copy of the second for animation purposes.

Except the uploader replaces the first frame with two copies of the second frame and makes the whole animation one frame longer.

EDIT: See reply.

Edited September 20, 2021 by Quarrel Kukulcan

[OptimoMaximo]

Long known viewer bug. So what? You can create your own percentage calculator if you need it, or make the calculation on the fly at upload time.

[Quarrel Kukulcan]

10 hours ago, OptimoMaximo said:

Long known viewer bug. So what?

Not one I was aware of, since it's not in the official wiki and there isn't a more-accurate alternative AFAIK.

Anyway, the joke's on you: I'm wrong. It's a fencepost error on my part. The Loop In/Loop Out frame panels in the Firestorm upload UI don't specify whole frames. They specify frame endpoints in time. "1" doesn't mean "all of frame 1", it means "the end of frame 1", which isn't exactly intuitive.

Ex: You make a 3-frame animation and want to loop the last two forever. Once you add the reference frame SL expects so it doesn't eat your real first one, you've got a 4-frame animation with your loop on 3 and 4. So Loop In should be 3 and Loop Out is 4, right?

Well...maybe. You'll get a transition from your frame 3 pose into your frame 4 pose but it will only last one frame's worth of realtime. "Loop In 3 / Loop Out 4" doesn't result in a loop where you're locked in pose 3 for one full tic, then locked in pose 4 for one full tic, which is what I was expecting. If it's more important to have 2 tics of delay (say, for timing reasons), you need to set Loop In to 2 -- and also align your endpoint keyframes differently to avoid snapback.

Now, sure, in an animation with hundreds of frames, this stuff isn't noticeable, but it's been glitching my gestures and short anims for the longest time and I've just now figured out why.

 

 

Edited September 20, 2021 by Quarrel Kukulcan

[OptimoMaximo]

On 9/20/2021 at 8:50 PM, Quarrel Kukulcan said:

Not one I was aware of, since it's not in the official wiki and there isn't a more-accurate alternative AFAIK.

Anyway, the joke's on you: I'm wrong. It's a fencepost error on my part. The Loop In/Loop Out frame panels in the Firestorm upload UI don't specify whole frames. They specify frame endpoints in time. "1" doesn't mean "all of frame 1", it means "the end of frame 1", which isn't exactly intuitive.

Ex: You make a 3-frame animation and want to loop the last two forever. Once you add the reference frame SL expects so it doesn't eat your real first one, you've got a 4-frame animation with your loop on 3 and 4. So Loop In should be 3 and Loop Out is 4, right?

Well...maybe. You'll get a transition from your frame 3 pose into your frame 4 pose but it will only last one frame's worth of realtime. "Loop In 3 / Loop Out 4" doesn't result in a loop where you're locked in pose 3 for one full tic, then locked in pose 4 for one full tic, which is what I was expecting. If it's more important to have 2 tics of delay (say, for timing reasons), you need to set Loop In to 2 -- and also align your endpoint keyframes differently to avoid snapback.

Now, sure, in an animation with hundreds of frames, this stuff isn't noticeable, but it's been glitching my gestures and short anims for the longest time and I've just now figured out why.

 

 

Well, you're not wrong. The looping point frame is basically tripled with the current behavior, reason why the stuttering at the loop point happens even though it shouldn't. Last frame is the same pose as the first 2 you're mentioning. If you search the forum post from well back to 2011/2012, you'll find plenty of explanations about this bug which was never mentioned in the wiki docs, as you found out yourself.