Second Life Forums Archive - Want better animations? Please read!

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

04-18-2008 07:28

If you'd like to see higher quality animations at lower prices, please vote for the JIRA entry listed below.

Making smooth animations for SL is frustrating because small or slow motions are lost on upload to SL. IMHO, this can be fixed without increasing lag. Many folks say that one cause for this is compression or optimization SL upload does to reduce animation file size. I'm confident that there are better ways to compress this data losslessly.

Strife says it's more due to low resolution of the data type used to hold joint rotations, and improving this might not be simple or feasible.

In any case, I'd like SL to address the problem -- at the very least by giving us clear information so we can write programs to filter animation files to minimize the effect of the problem.

If you'd like to see higher quality animations at a lower price, please vote for this JIRA entry! Note that I would NOT be in favor of a "solution" that increases lag, and I'm confident there are solutions that would not do so.

http://jira.secondlife.com/browse/VWR-2461
http://jira.secondlife.com/browse/VWR-2461

Thanks!

Amity Slade

Registered User

Join date: 14 Feb 2007

Posts: 2,183

04-18-2008 16:05

Done.

The largest barrier to creating animations is all the extra endless hours of work created by the animation "optimization" process. It's difficult to guess how the optimization process will change the animation. Then one has to go back to create revision after revision, with only some vague idea of why the optimization process changed the animation and what to do about it.

Animation would be a much more accessible area of content creation if the optimization process were either eliminated, or, if not eliminated, documented so that animators can save lots of work by creating animations that work as expected the first time around.

Nika Talaj

now you see her ...

Join date: 2 Jan 2007

Posts: 5,449

04-18-2008 16:43

Voted and commented.
.

SuezanneC Baskerville

Forums Rock!

Join date: 22 Dec 2003

Posts: 14,229

04-18-2008 16:49

Is the optimization process done by the viewer or on the server?

_____________________

-

So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them.

I can be found on the web by searching for "SuezanneC Baskerville", or go to

http://www.google.com/profiles/suezanne

-

http://lindenlab.tribe.net/ created on 11/19/03.

Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard,
Robin, and Ryan

-

Chip Midnight

ate my baby!

Join date: 1 May 2003

Posts: 10,231

04-18-2008 17:25

From: SuezanneC Baskerville

Is the optimization process done by the viewer or on the server?

It's done by the viewer. No compression takes place on upload. It's a text file that describes keyframes and bone rotations. How could it be compressed? The quality of the animation for the viewer depends entirely on the viewer's frame rate.

Here are some comments by Xenon Linden from a thread about animation keyframing...

From: Xenon Linden

There's no penalty for uploading animations created at 60 fps vs 15 fps in SL, storage- or playback performance- wise.

My suggestion to animate at 15 fps is simply to help insure that the important details of your animation come through when they are playing back at different fps on different viewers, 15 fps being about the average viewer framerate.

As an extreme example, think about animating a character doing a series of hypersonic jumping jacks. With 2 keyframes set for each jumping jack (open arms/legs and closed arms/legs), if you animate at 60 fps you could create a maximum of 30 jumping jacks in one second. But if that animation played back on a viewer running at only 15 fps, the playback would essentially skip 3 out of 4 frames and all that detail you took the time to animate would be lost.

If you re-create the same animation at 15 fps, you could animate about 7 distinct hyperjacks in one second. If that animation played back in a viewer running at 60 fps(rare, but it happens

), the viewer would interpolate the motion between those keyframes and you would see 7 very smooth, distinct jumping jacks, actually improving the quality of your animation without loosing detail.

Really, you should animate at whatever framerate you are comfortable with since you can always retime the animation later at a lower framerate to test, or even check it in SL's animation preview window. You might try animating at 24 or 30 fps, since those are standard rates for film and video. 12 fps is the bare minimum for most people to perceive the illusion of motion, and most people can't discern more detail in motion above about 60 fps.

-Xenon

That was from this thread: /52/1d/15623/1.html

_____________________

My other hobby:
www.live365.com/stations/chip_midnight

Anti Antonelli

Deranged Toymaker

Join date: 25 Apr 2006

Posts: 1,091

04-18-2008 18:37

From: Chip Midnight

No compression takes place on upload. It's a text file that describes keyframes and bone rotations. How could it be compressed? The quality of the animation for the viewer depends entirely on the viewer's frame rate.

That's not true. Xenon's points about framerates still stand, but s/he failed to mention the following:

http://wiki.secondlife.com/wiki/Animation

From: someone

9. Optimization
SL's BVH importer does optimization of animation data prior to upload into SL. Joint rotations with very slight changes from keyframe to keyframe will be interpreted as *not* changing and thus aren't stored. This is done intentionally since custom animation data is stored on our servers and downloaded to each viewer as it is needed in real time, and needs to be fairly terse.
The potential side effect of the optimization is what you have observed; joints with very subtle movement might have their animation data dropped entirely on upload. The threshold formula is complex, and involves comparing all three axes of data per joint, the distance moved between keyframes, as well as the joint's position in the skeletal hierachy.

That's the main contributor to the types of problems Lear mentions. It's been discussed to death in the animation forum over the years.

_____________________

Designer of sensual, tasteful couple's animations - for residents who take their leisure time seriously.

http://slurl.com/secondlife/Brownlee/203/110/109/

Amity Slade

Registered User

Join date: 14 Feb 2007

Posts: 2,183

04-18-2008 19:04

Making animations using lower fps rates helps to cope somewhat with the "optimization."

However, even at low fps rates (I've been using 12 fps for animations recently), the "optimization" still screws up movements that I would not describe as subtle.

I've been creating animations for SL for over a year, and reading all I can about them, and the "optimization" process remains an unpredictable mystery to me.

It would be nice to know a little bit more about how "optimization" works at a minimum. The better I can plan for what "optimization" will do to my animation, the better and more efficiently I can make animations.

Whether it's by documenting "optimization," or removing it, a change would make animation a much more accessible area of content creation for residents in the world meant to be created by residents.

Chip Midnight

ate my baby!

Join date: 1 May 2003

Posts: 10,231

04-18-2008 19:16

Never knew that. It would be good to know exactly what the threshold is for a key to be considered significant enough not to be dropped.

_____________________

My other hobby:
www.live365.com/stations/chip_midnight

Kitty Barnett

Registered User

Join date: 10 May 2006

Posts: 5,586

04-18-2008 19:30

From: Chip Midnight

It's done by the viewer.

If it's entirely client-side, what's to keep anyone from simply commenting out the "optimization" in a custom viewer and upload at full detail?

SuezanneC Baskerville

Forums Rock!

Join date: 22 Dec 2003

Posts: 14,229

04-18-2008 19:32

Could the situation be improved by a standalone animation previewer?

If the compression is done in the viewer then source code should reveal the details, assuming one can read source code.

_____________________

-

So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them.

I can be found on the web by searching for "SuezanneC Baskerville", or go to

http://www.google.com/profiles/suezanne

-

http://lindenlab.tribe.net/ created on 11/19/03.

Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard,
Robin, and Ryan

-

Johan Durant

Registered User

Join date: 7 Aug 2006

Posts: 1,657

04-18-2008 19:50

From: SuezanneC Baskerville

assuming one can read source code.

_____________________

(Aelin 184,194,22)

The Motion Merchant - an animation store specializing in two-person interactions

Anti Antonelli

Deranged Toymaker

Join date: 25 Apr 2006

Posts: 1,091

04-18-2008 19:51

From: Kitty Barnett

If it's entirely client-side, what's to keep anyone from simply commenting out the "optimization" in a custom viewer and upload at full detail?

That's a good thought, but I suspect there are server-side checks in place that at least ensure the "optimized" file isn't too large, and may be checking for other more subtle deviations from the expected upload. Been at least one thread by a confused animator who was getting errors along the lines of "animation file too large". Not sure what caused that, but the presence of the error message seems pretty telling.

From: SuezanneC Baskerville

Could the situation be improved by a standalone animation previewer?

I'm not sure why LL created the previewer at all when they could have just displayed the animation on the avatar of the person uploading. (Picture something like the "editing appearance" UI.) I can think of other benefits too, such as being able to preview with different shapes and checking the movement of attachments. That said, the issue at hand isn't about being able to *see* the results of the optimization process; it's about being able to predict the results, and the fact that the results can be so disappointing.

From: someone

If the compression is done in the viewer then source code should reveal the details, assuming one can read source code.

Amen, I'd love it if a coder would take a look and post a formula or pseudocode or something.

_____________________

Designer of sensual, tasteful couple's animations - for residents who take their leisure time seriously.

http://slurl.com/secondlife/Brownlee/203/110/109/

Lamia Shan

Registered User

Join date: 9 Jul 2007

Posts: 11

04-18-2008 20:16

Just after I joined I spent a lot of time on various SL forums reading about why animations where not been uploaded as they where created. I think it was a post in the animation forum (I can’t find it at the moment) that suggested 1 degree of movement in 12 frames per each axis of movement, of each limb, @30fps was the threshold before frames got culled. Either the movement was lost on upload or limbs started to drift.

From animations I have done over the last year it seems to hold true.

Kitty Barnett

Registered User

Join date: 10 May 2006

Posts: 5,586

04-18-2008 20:28

From: Anti Antonelli

Amen, I'd love it if a coder would take a look and post a formula or pseudocode or something.

http://svn.secondlife.com/trac/linden/browser/release/indra/llcharacter/llbvhloader.cpp#L1081

Not much help, but there's the code

.

Lear Cale

wordy bugger

Join date: 22 Aug 2007

Posts: 3,569

04-18-2008 23:46

Excellent, Kitty.

I'll see if I can code that into a filter program folks can run on a BVH file to see how it would look without going ingame.

Thanks, big time.

Gabriele Graves

Always and Forever, FULL

Join date: 23 Apr 2007

Posts: 6,205

04-20-2008 19:53

From: Kitty Barnett

http://svn.secondlife.com/trac/linden/browser/release/indra/llcharacter/llbvhloader.cpp#L1081

Not much help, but there's the code

.

Looks to me like you could get rid of the code in the lines 1232-1236 and that would get rid of the optimizations only.

Hope that helps someone

_____________________

Trout Rating: I'm giving you an 8.2 on the Troutchter Earth-Movement Slut Scale. You are an amazing, enchanting woman, and, when the situation calls for it, a slut of the very best sort. Congratulations and shame on you!

Want better animations? Please read!
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	04-18-2008 07:28 If you'd like to see higher quality animations at lower prices, please vote for the JIRA entry listed below. Making smooth animations for SL is frustrating because small or slow motions are lost on upload to SL. IMHO, this can be fixed without increasing lag. Many folks say that one cause for this is compression or optimization SL upload does to reduce animation file size. I'm confident that there are better ways to compress this data losslessly. Strife says it's more due to low resolution of the data type used to hold joint rotations, and improving this might not be simple or feasible. In any case, I'd like SL to address the problem -- at the very least by giving us clear information so we can write programs to filter animation files to minimize the effect of the problem. If you'd like to see higher quality animations at a lower price, please vote for this JIRA entry! Note that I would NOT be in favor of a "solution" that increases lag, and I'm confident there are solutions that would not do so. http://jira.secondlife.com/browse/VWR-2461 http://jira.secondlife.com/browse/VWR-2461 Thanks!
Amity Slade Registered User Join date: 14 Feb 2007 Posts: 2,183	04-18-2008 16:05 Done. The largest barrier to creating animations is all the extra endless hours of work created by the animation "optimization" process. It's difficult to guess how the optimization process will change the animation. Then one has to go back to create revision after revision, with only some vague idea of why the optimization process changed the animation and what to do about it. Animation would be a much more accessible area of content creation if the optimization process were either eliminated, or, if not eliminated, documented so that animators can save lots of work by creating animations that work as expected the first time around.
Nika Talaj now you see her ... Join date: 2 Jan 2007 Posts: 5,449	04-18-2008 16:43 Voted and commented. .
SuezanneC Baskerville Forums Rock! Join date: 22 Dec 2003 Posts: 14,229	04-18-2008 16:49 Is the optimization process done by the viewer or on the server? _____________________ - So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them. I can be found on the web by searching for "SuezanneC Baskerville", or go to http://www.google.com/profiles/suezanne - http://lindenlab.tribe.net/ created on 11/19/03. Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard, Robin, and Ryan -
Chip Midnight ate my baby! Join date: 1 May 2003 Posts: 10,231	04-18-2008 17:25 From: SuezanneC Baskerville Is the optimization process done by the viewer or on the server? It's done by the viewer. No compression takes place on upload. It's a text file that describes keyframes and bone rotations. How could it be compressed? The quality of the animation for the viewer depends entirely on the viewer's frame rate. Here are some comments by Xenon Linden from a thread about animation keyframing... From: Xenon Linden There's no penalty for uploading animations created at 60 fps vs 15 fps in SL, storage- or playback performance- wise. My suggestion to animate at 15 fps is simply to help insure that the important details of your animation come through when they are playing back at different fps on different viewers, 15 fps being about the average viewer framerate. As an extreme example, think about animating a character doing a series of hypersonic jumping jacks. With 2 keyframes set for each jumping jack (open arms/legs and closed arms/legs), if you animate at 60 fps you could create a maximum of 30 jumping jacks in one second. But if that animation played back on a viewer running at only 15 fps, the playback would essentially skip 3 out of 4 frames and all that detail you took the time to animate would be lost. If you re-create the same animation at 15 fps, you could animate about 7 distinct hyperjacks in one second. If that animation played back in a viewer running at 60 fps(rare, but it happens ), the viewer would interpolate the motion between those keyframes and you would see 7 very smooth, distinct jumping jacks, actually improving the quality of your animation without loosing detail. Really, you should animate at whatever framerate you are comfortable with since you can always retime the animation later at a lower framerate to test, or even check it in SL's animation preview window. You might try animating at 24 or 30 fps, since those are standard rates for film and video. 12 fps is the bare minimum for most people to perceive the illusion of motion, and most people can't discern more detail in motion above about 60 fps. -Xenon That was from this thread: /52/1d/15623/1.html _____________________ My other hobby: www.live365.com/stations/chip_midnight
Anti Antonelli Deranged Toymaker Join date: 25 Apr 2006 Posts: 1,091	04-18-2008 18:37 From: Chip Midnight No compression takes place on upload. It's a text file that describes keyframes and bone rotations. How could it be compressed? The quality of the animation for the viewer depends entirely on the viewer's frame rate. That's not true. Xenon's points about framerates still stand, but s/he failed to mention the following: http://wiki.secondlife.com/wiki/Animation From: someone 9. Optimization SL's BVH importer does optimization of animation data prior to upload into SL. Joint rotations with very slight changes from keyframe to keyframe will be interpreted as not changing and thus aren't stored. This is done intentionally since custom animation data is stored on our servers and downloaded to each viewer as it is needed in real time, and needs to be fairly terse. The potential side effect of the optimization is what you have observed; joints with very subtle movement might have their animation data dropped entirely on upload. The threshold formula is complex, and involves comparing all three axes of data per joint, the distance moved between keyframes, as well as the joint's position in the skeletal hierachy. That's the main contributor to the types of problems Lear mentions. It's been discussed to death in the animation forum over the years. _____________________ Designer of sensual, tasteful couple's animations - for residents who take their leisure time seriously. http://slurl.com/secondlife/Brownlee/203/110/109/
Amity Slade Registered User Join date: 14 Feb 2007 Posts: 2,183	04-18-2008 19:04 Making animations using lower fps rates helps to cope somewhat with the "optimization." However, even at low fps rates (I've been using 12 fps for animations recently), the "optimization" still screws up movements that I would not describe as subtle. I've been creating animations for SL for over a year, and reading all I can about them, and the "optimization" process remains an unpredictable mystery to me. It would be nice to know a little bit more about how "optimization" works at a minimum. The better I can plan for what "optimization" will do to my animation, the better and more efficiently I can make animations. Whether it's by documenting "optimization," or removing it, a change would make animation a much more accessible area of content creation for residents in the world meant to be created by residents.
Chip Midnight ate my baby! Join date: 1 May 2003 Posts: 10,231	04-18-2008 19:16 Never knew that. It would be good to know exactly what the threshold is for a key to be considered significant enough not to be dropped. _____________________ My other hobby: www.live365.com/stations/chip_midnight
Kitty Barnett Registered User Join date: 10 May 2006 Posts: 5,586	04-18-2008 19:30 From: Chip Midnight It's done by the viewer. If it's entirely client-side, what's to keep anyone from simply commenting out the "optimization" in a custom viewer and upload at full detail?
SuezanneC Baskerville Forums Rock! Join date: 22 Dec 2003 Posts: 14,229	04-18-2008 19:32 Could the situation be improved by a standalone animation previewer? If the compression is done in the viewer then source code should reveal the details, assuming one can read source code. _____________________ - So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them. I can be found on the web by searching for "SuezanneC Baskerville", or go to http://www.google.com/profiles/suezanne - http://lindenlab.tribe.net/ created on 11/19/03. Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard, Robin, and Ryan -
Johan Durant Registered User Join date: 7 Aug 2006 Posts: 1,657	04-18-2008 19:50 From: SuezanneC Baskerville assuming one can read source code. _____________________ (Aelin 184,194,22) The Motion Merchant - an animation store specializing in two-person interactions
Anti Antonelli Deranged Toymaker Join date: 25 Apr 2006 Posts: 1,091	04-18-2008 19:51 From: Kitty Barnett If it's entirely client-side, what's to keep anyone from simply commenting out the "optimization" in a custom viewer and upload at full detail? That's a good thought, but I suspect there are server-side checks in place that at least ensure the "optimized" file isn't too large, and may be checking for other more subtle deviations from the expected upload. Been at least one thread by a confused animator who was getting errors along the lines of "animation file too large". Not sure what caused that, but the presence of the error message seems pretty telling. From: SuezanneC Baskerville Could the situation be improved by a standalone animation previewer? I'm not sure why LL created the previewer at all when they could have just displayed the animation on the avatar of the person uploading. (Picture something like the "editing appearance" UI.) I can think of other benefits too, such as being able to preview with different shapes and checking the movement of attachments. That said, the issue at hand isn't about being able to see the results of the optimization process; it's about being able to predict the results, and the fact that the results can be so disappointing. From: someone If the compression is done in the viewer then source code should reveal the details, assuming one can read source code. Amen, I'd love it if a coder would take a look and post a formula or pseudocode or something. _____________________ Designer of sensual, tasteful couple's animations - for residents who take their leisure time seriously. http://slurl.com/secondlife/Brownlee/203/110/109/
Lamia Shan Registered User Join date: 9 Jul 2007 Posts: 11	04-18-2008 20:16 Just after I joined I spent a lot of time on various SL forums reading about why animations where not been uploaded as they where created. I think it was a post in the animation forum (I can’t find it at the moment) that suggested 1 degree of movement in 12 frames per each axis of movement, of each limb, @30fps was the threshold before frames got culled. Either the movement was lost on upload or limbs started to drift. From animations I have done over the last year it seems to hold true.
Kitty Barnett Registered User Join date: 10 May 2006 Posts: 5,586	04-18-2008 20:28 From: Anti Antonelli Amen, I'd love it if a coder would take a look and post a formula or pseudocode or something. http://svn.secondlife.com/trac/linden/browser/release/indra/llcharacter/llbvhloader.cpp#L1081 Not much help, but there's the code .
Lear Cale wordy bugger Join date: 22 Aug 2007 Posts: 3,569	04-18-2008 23:46 Excellent, Kitty. I'll see if I can code that into a filter program folks can run on a BVH file to see how it would look without going ingame. Thanks, big time.
Gabriele Graves Always and Forever, FULL Join date: 23 Apr 2007 Posts: 6,205	04-20-2008 19:53 From: Kitty Barnett http://svn.secondlife.com/trac/linden/browser/release/indra/llcharacter/llbvhloader.cpp#L1081 Not much help, but there's the code . Looks to me like you could get rid of the code in the lines 1232-1236 and that would get rid of the optimizations only. Hope that helps someone _____________________ Trout Rating: I'm giving you an 8.2 on the Troutchter Earth-Movement Slut Scale. You are an amazing, enchanting woman, and, when the situation calls for it, a slut of the very best sort. Congratulations and shame on you!

Welcome to the Second Life Forums Archive

Want better animations? Please read!