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

From Second Life Wiki
Jump to navigation Jump to search
m (moved Animating Breathing and Other Subtle Movements to Animating Breathing and Other Subtle Motion: consistency with the subsection names, and more natural sounding English)
(10 intermediate revisions by the same user not shown)
Line 2: Line 2:
|Object=*
|Object=*
}}
}}
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.
 
Many animators report difficulties with subtle motion.  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.
Hopefully this article will clear up some misunderstandings.
Line 17: Line 18:
{|{{prettytable}}
{|{{prettytable}}
|-{{Hl2}}
|-{{Hl2}}
!Activity
! Activity
!Breaths Per Minute
! Breaths Per Minute
|-
|-
|breathing meditation
| breathing meditation
|5
| 5
|-
|-
|at rest or sleeping
| at rest or sleeping
|12
| 12
|-
|-
|average adults doing strenuous work
| average adults doing strenuous work
|40
| 40
|-
|-
|athletes at peak
| athletes at peak
|65
| 65
|}
|}


Line 38: Line 39:
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 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 file 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 using 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 a value that is stored, and one that is not, you can start repeatedly halving the distance.  This can be achieved by averaging the high and low numbers, or using the following formula:
 
(high - low)/2 + low
 
Since averaging is simpler and faster, I suggest that method.
 
For example:
* you start with 1 degree, and find it stored
* then try 0.0001 degree, and find it is not stored
* (1 + 0.0001)/2 = 0.5000
* you find that 0.5000 is stored
* (0.5000 + 0.0001)/2 = 0.2500
* you find that 0.2500 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 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 circumstances.  Such changes are so small that they could be caused by rounding errors.  32-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 visible.  Put 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 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.


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.
As you can see, even very faint breathing will survive Second Life's lossy compression.


Suffice it to say, if you think your animation looks wrong due to lossy compression, that is unlikely to be the case.  It 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.
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.


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.
Likely explanations for visible imperfections in animations include:
* you forgot to take off your animation overrider when testing the animation, resulting in unexpected mixing
* your 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 ==
*[[Animation Reference Frame]]
*[[Animation Upload Priority]]
*[[Animation Upload Priority]]
*[[BVH Hip Location Limits]]
*[[BVH Reference Frame]]


[[Category:LSL_Animation]]
[[Category:LSL_Animation]]

Revision as of 02:10, 14 July 2012

Many animators report difficulties with subtle motion. 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 file 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 using 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 a value that is stored, and one that is not, you can start repeatedly halving the distance. This can be achieved by averaging the high and low numbers, or using the following formula:

(high - low)/2 + low

Since averaging is simpler and faster, I suggest that method.

For example:

  • you start with 1 degree, and find it stored
  • then try 0.0001 degree, and find it is not stored
  • (1 + 0.0001)/2 = 0.5000
  • you find that 0.5000 is stored
  • (0.5000 + 0.0001)/2 = 0.2500
  • you find that 0.2500 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
  • your 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

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Animating_Breathing_and_Other_Subtle_Motion&oldid=1170587"