Database Reference
In-Depth Information
Table 3: Life forms application variables
1
The image environment
2620 bytes
Stage, time line, fi gure editor, panel
2
Every image
1492 bytes
3
Frame per second variation
20 bytes To defi ne motion velocity
4
Change of location
20 bytes
Location change on the horizontal plane
5
Change of altitude
18 bytes
Location change on the vertical plane
Change of facing - rotation
18-36 bytes
The rate of change dictates the volume
6
7
Limb representation in every position
368 bytes
takes only 324 - 1540 bits (depending on sampling frequency), a factor of 22.1 to 105
in storage saving.
We should note, however, that this velocity defi nition is limited and distorted, since
it ascribes a velocity profi le of motion as a whole, instead of a specifi c velocity profi le for
each limb separately.
Thus, in a
worst-case
analysis with a sampling frequency of 10 frames per second
(FPS) (most animation programs use a 3 FPS default, an animation suffi ciently smooth
for the human eye), our model needs
1,540 bits per second
(10 samplings per second *
7 bits per limb * 22 limbs). Note that there is no need to use all seven bits for each of the
22 limbs, because few limbs have more than one degree of freedom; that is, most limbs
can be represented by a 3-bit byte per time unit. In the examples we used the full 7-bit
motion byte in volume consumption calculations, to be on the safe side. In a
best-case
analysis
,
given a sampling frequency of three frames per second, eight limbs with one
degree of freedom (i.e., representation by a 3-bit motion byte), seven limbs with two de-
grees of freedom (represented by a 5-bit motion byte), and seven limbs with three degrees
of freedom (represented by a 7-bit motion byte), our model requires
324 bits per second
(3 samplings per second * [8 limbs * 3 bits + 7 limbs * 5 bits + 7 limbs * 7 bits]).
In contrast, to represent and store
one second
of an arm movement through an angle of
more than 180 degrees (as illustrated in Figure 9), the Life Forms application requires
14,592
bits.
This gives a ratio of
1:45
in favor of our model (depending on sampling frequency).
These examples, and others performed for the comparison, clearly demonstrate that in
the key frames approach storage volume grows signifi cantly in accordance with the number
of moving limbs and the velocity of each limb participating in the motion. The binary model,
on the other hand, is virtually independent of motion and velocity of the various limbs. The
only signifi cant parameters are the number of limbs and the desired sampling frequency.
The advantages of the binary model become more evident when we compare the volumes
needed for motion storage, whose representation by means of the key frames approach
demands the defi nition and representation of an intermediate position.
MOTION LANGUAGE
While the design of a motion language is beyond the scope of this paper, our work
provides some guidelines for producing the “letters”, “words”, and “sentences” leading to a
motion text. The examples in this paper show some initial steps: the 7-bit motion byte defi nes
