Difference between revisions of "Animating Breathing and Other Subtle Motion"

From Second Life Wiki
Jump to navigation Jump to search
Line 38: Line 38:
Second Life lossily compresses animations.  This has raised concern about subtle motions being stripped, and questions about how subtle a motion can be before it is removed.
Second Life lossily compresses animations.  This has raised concern about subtle motions being stripped, and questions about how subtle a motion can be before it is removed.


If my understanding is correct, the internal format used for animations could be compared to a music box.  Each joint corresponds to a location along the cylinder, and joint changes are like pins along the cylinder.  The passage of time is like the rotation of the cylinder, which, in a music box, causes the pins to pluck the notes, and in Second Life, cause the joint values to update.
The following information was gathered by testing.


The compression algorithm seems to remove joint changes of less than 0.001 (degrees or inches) from the last joint position that it retained.  Even at 45 frames per second, joint changes of less than 0.001 would be so subtle as to be invisible under normal circumstancesSuch changes are so small that they could be caused by rounding errors32-bit floating point numbers, which are used for most 3-D operations, only have a significand of about 7 decimal digits. This process is probably necessary to remove duplicate keyframes which consume space but are not visiblePut another way, this is the way the algorithm decides whether a value should be treated as a joint change (like a pin on the cylinder), or ignored (like empty space on the cylinder).
The minimum location change that is stored is 0.0057 inches, and a rotation change of 0.0053 degrees is always storedOnly the hip can be relocatedJoints nearer the hip will store rotations less than 0.0053For instance, the minimum Thigh rotation that is stored is 0.0019.


I created a animation for breathing meditation, at 5 breaths per minute, at 45 frames per second.  This should be the worst case scenario for a realistic animation, since the rate of change is extremely slow, and the change in values between frames is extremely small, and thus likely to be stripped.  I then started reducing the amount the chest joint rocked to see when the motion would be lost.  At 3 degrees I found the motion impossible to detect visually.  I managed to make the motion visible by sitting on a cube, wearing a pitch black skin, and pressing another, stark white, cube against my back until part of my back clipped through the surface of the white prim.  This resulted in slowly moving patterns on the surface of the white prim that looked something like a animated Rorschach test.  I was still able to detect the motion at 1 degree.  That means a 1 degree change in 405 frames at 45 FPS was retained.  I gave up at that point.
The minimum location and rotation change that is stored is the same regardless of BVH frame rate.


Suffice it to say, if you think your animation looks wrong due to lossy compression, that is unlikely to be the caseIt is much more likely that your reference frame or priority is wrong.  Also be sure you don't have a animation overrider on causing unexpected mixing as you test your animation.
Lossiness is not effected by the speed of changeThe minimum location and rotation change that is stored is the same regardless of the number of frames it's spread across.


Lear Cale adds: I know for a fact that the paragraph above is inaccurate, and will demonstrate it.  Stay tuned! However, I do not dispute the claim that it's possible to make smooth breathing despite this issue.
These results were obtained by using a cube and a skin that were sharply contrasting, moving the cube to clip through the avatar, and watching the area where the avatar met the surface of the cube for movement.  This was necessary since the motions that are lost are so small.
 
The amount of time it takes to find the cutoff can be reduced by applying a algorithm similar to binary search.  Specifically...  Start with a value you think will be near the cutoff.  Note whether or not it is storedIf it's stored, try a lower value. If not, try a higher value.  Once you find at least one value that is stored, and one that is not, you can start repeatedly halving the distance.
 
For example:
* you start with 1 degree, find it stored
* then try 0.0001 degree, find it is not stored
* then divide the difference by two (1-0.0001)/2 = 0.4999
* you find that 0.4999 is stored
* you divide the difference between the lowest number you found to be stored and the highest number you found not to be stored (0.4999-0.0001)/2 = 0.2499
* you find that 0.2499 is stored...
 
Those wishing to repeat the experiment may find it helpful to use a viewer that allows you to: disable the minimum camera zoom distance, allow the camera to move without constraints through prims, and provides in-world animation preview.  The first two features make it easier to notice movements this small.  The last one will save you lindens if you're not doing the testing on the Beta Grid and allows you to avoid waiting on the animation to upload, which is useful because you would be uploading a very large number of animations otherwise.  An example of a viewer with these features is [http://www.phoenixviewer.com/ Phoenix] (free and open source).
 
The tool used to produce the animation must be accurate.  This is fairly easy to verify by opening the BVH files in a text editor since they are human readable.  [http://www.qavimator.org/ QAvimator] (free and open source) is sufficient for this purpose.
 
As you can see, even very faint breathing will survive Second Life's lossy compression.
 
Since the changes removed by Second Life's lossy compression are so small, you should check for other possible explanations before concluding that is the source of your problem.
 
Likely explanations for visible imperfections in animations include:
* you forgot to take off your animation overrider when testing the animation, resulting in unexpected mixing
* the BVH file has a incorrect reference frame
* you uploaded at the wrong priority
* you struck the hip location limits
* the animation exporter is incorrectly configured (Second Life uses inches for location changes, rather than metric units, which is a likely source of problems)
* the animation exporter is flawed (check your animation in a offline viewer like [http://davedub.co.uk/bvhacker/ bvhacker] or [http://www.qavimator.org/ QAvimator], both of which are free)


== See Also ==
== See Also ==

Revision as of 00:49, 5 March 2011

Many animators report difficulties with subtle movements. One of the most subtle movements one might need to animate is breathing, and it's also one of the most common tasks a animator will face, since almost every animation should include breathing.

Hopefully this article will clear up some misunderstandings.

Breathing

Breathing is simulated in Second Life by rocking the chest joint along the X axis, since it is impossible to expand and contract the chest and stomach.

Both the depth and rate of breathing varies depending on the activity of the person in question.

Since people don't really breath by rocking back and forth, it's impossible to say what the range of motion should be on the chest joint, but a good upper limit would be about 10 degrees. If you go much beyond that it starts looking too exaggerated.

The respiration rate of an adult human is bounded. Respiration rates of less than 3 or more than 70 breaths per minute are unheard of.

Activity Breaths Per Minute
breathing meditation 5
at rest or sleeping 12
average adults doing strenuous work 40
athletes at peak 65

Breathing meditation is something of a special case. Normally inhalation and exhalation take about the same amount of time, but during breathing meditation the exhalation consumes about 3/4ths of the time. The breaths are also very deep.

Subtle Motion

Second Life lossily compresses animations. This has raised concern about subtle motions being stripped, and questions about how subtle a motion can be before it is removed.

The following information was gathered by testing.

The minimum location change that is stored is 0.0057 inches, and a rotation change of 0.0053 degrees is always stored. Only the hip can be relocated. Joints nearer the hip will store rotations less than 0.0053. For instance, the minimum Thigh rotation that is stored is 0.0019.

The minimum location and rotation change that is stored is the same regardless of BVH frame rate.

Lossiness is not effected by the speed of change. The minimum location and rotation change that is stored is the same regardless of the number of frames it's spread across.

These results were obtained by using a cube and a skin that were sharply contrasting, moving the cube to clip through the avatar, and watching the area where the avatar met the surface of the cube for movement. This was necessary since the motions that are lost are so small.

The amount of time it takes to find the cutoff can be reduced by applying a algorithm similar to binary search. Specifically... Start with a value you think will be near the cutoff. Note whether or not it is stored. If it's stored, try a lower value. If not, try a higher value. Once you find at least one value that is stored, and one that is not, you can start repeatedly halving the distance.

For example:

  • you start with 1 degree, find it stored
  • then try 0.0001 degree, find it is not stored
  • then divide the difference by two (1-0.0001)/2 = 0.4999
  • you find that 0.4999 is stored
  • you divide the difference between the lowest number you found to be stored and the highest number you found not to be stored (0.4999-0.0001)/2 = 0.2499
  • you find that 0.2499 is stored...

Those wishing to repeat the experiment may find it helpful to use a viewer that allows you to: disable the minimum camera zoom distance, allow the camera to move without constraints through prims, and provides in-world animation preview. The first two features make it easier to notice movements this small. The last one will save you lindens if you're not doing the testing on the Beta Grid and allows you to avoid waiting on the animation to upload, which is useful because you would be uploading a very large number of animations otherwise. An example of a viewer with these features is Phoenix (free and open source).

The tool used to produce the animation must be accurate. This is fairly easy to verify by opening the BVH files in a text editor since they are human readable. QAvimator (free and open source) is sufficient for this purpose.

As you can see, even very faint breathing will survive Second Life's lossy compression.

Since the changes removed by Second Life's lossy compression are so small, you should check for other possible explanations before concluding that is the source of your problem.

Likely explanations for visible imperfections in animations include:

  • you forgot to take off your animation overrider when testing the animation, resulting in unexpected mixing
  • the BVH file has a incorrect reference frame
  • you uploaded at the wrong priority
  • you struck the hip location limits
  • the animation exporter is incorrectly configured (Second Life uses inches for location changes, rather than metric units, which is a likely source of problems)
  • the animation exporter is flawed (check your animation in a offline viewer like bvhacker or QAvimator, both of which are free)

See Also