Upload a1

1 files changed, 0 insertions, 479 deletions

diff --git a/dev/a4-dance/data/format.txt b/dev/a4-dance/data/format.txt
deleted file mode 100644
index b949594..0000000
--- a/dev/a4-dance/data/format.txt
+++ /dev/null
@@ -1,479 +0,0 @@
-Title: Acclaim Skeleton File Definition V1.10
-
-M.Schafer    29 Feb 1995.
-
-     This file format defines a skeleton in terms of its shape,
-hierarchy, and the properties of its joints and bones.  It is intended as
-a human readable exchange format between different skeletal animation
-systems.  This is the format used by the Acclaim Motion Capture System.
-The Acclaim system is based on joint rotation data. The file format will
-work equally well with positional only data systems. Due to the 
-rotational basis of Acclaim's motion capture data, motion data files are 
-matched to specific skeletons. They will not work as expected on
-arbitrary shaped or connected skeletons.  Therefore this definition is
-necessary to ensure that motion data files will work as expected.
-     This file does not define how the skeleton affects the skin.  That
-information is vendor specific.  It is recommended that Vendors are able
-to convert their skeletal system data structures to and from this
-format.  Vendors may adopt this format as their own. Please address all 
-requests for additional fields, changes or queries to Acclaim ATG.
-
-Acclaim ATG (516) 656-5000. One Acclaim Plaza. Glen Cove.
-  NY 11542-2708.
-
-The File format: (text)
-
-# comment, ignore text to end of line 
-# , commas and () parenthesis are used as whitespace.
-# commas are discouraged. Please use spaces instead.
-:version 1.10                  # float        (version of this file format) 
-:name xxxxxxxxxxxxxxxxxxxx     # string[50]   (name of skeleton) 
-:units                         #              (multipliers for different 
-  mass 1.0                     # float           unit systems ) 
-  length 1.0                   # float 
-  angle deg                    # token        (rad or deg) 
-:documentation 
-  place any notes here.
-  Documentation is read until the next line that starts with a keyword.
-
-:root
-  axis xyz                     # token    (rot. order for orientation offset)
-  order tx ty tz rz ry rx      # tokens   (order of transformation for root)
-  position 0.0 0.0 0.0         # float x3 (translation offset for root node 
-                               #             to position the skeleton) 
-  orientation 0.0 0.0 0.0      # float x3 (rotation offset)
-
-:bonedata                      #          (definition data for all the bones)
-  begin                        #          (delimiter)
-    id 1                       # int      (opt. unique numeric id.)
-    name h_waist               # string   (uses the body naming convention)
-    direction 0.0 1.0 0.0      # float x3 (direction vector of bone)
-    length 3.0                 # float        (length of bone)
-    axis 0.0 90.0 0.0 zyx      # float x3 xyz (global orientation of the
-                                               axis, the xyz token specifies
-                                               order of rotation)
-    dof tx ty tz rx ry rz l    # tokens       (only include tokens required.)
-    limits (-inf inf)          # float/token  (lower and upper limit for
-           (-inf inf)          #               each degree of freedom given
-           (-inf inf)          #               above.  inf = infinity.)
-           (-l80 180) 
-           (0 180.0) 
-           (-90.0 90.0) 
-           (0.5 4.5)
-    bodymass 10.0              # float    (opt. mass of skinbody assoc with
-                               #           this bone)
-    cofmass 1.0 end            # float    (opt. position of cofm along bone)
-  end
-
-  begin                        # the next bone
-    name h_R_hip 
-    direction 0.0 1.0 0.0      # bone points straight up
-    length 2.5 
-    axis 0.0 90.0 0.0 zxy      # the local coordinate system is rotated
-    dof rx l                   #  90 degrees about the global Y-axis.
-    limits (-120 60.0) 
-           (2.5 4.0)           # i.e. can't get any shorter.
-  end
-  "                            # etc until all bones specified.
-  "
-
-:hierarchy 
-  begin 
-    root h_waist h_R_hip h_L_hip     # parents followed by children
-    h_waist h_torso_2                # the root is implied as the first
-                                     #  element although it is not a bone
-      "  "                           #  but a location.
-
-      "  "                           # etc until all hierarchy defined
-  end
-
-:skin filename      # filename to use on this skeleton
-      filename      # a second skin. E.g. block figure, med res
-       "   "        #  and high res skins.
-
-Notes:
-
-Parentheses and commas were designed to be seen as whitespace. Commas 
-have caused problems with some readers, however, and are therefore 
-discouraged. Spaces are preferable.
-The keywords appear in the following order:
-     :version, :name, :units, :documentation, :root, :bonedata, 
-     :hierarchy, and :skin.
-     Units and skin are optional.
-
-There are several elements of the file which are designed to make the 
-file more human readable. For example the bone's orientation is in 
-global space although the skeleton is hierarchical. The internal 
-representation of a skeleton will be dependent on specific vendors 
-implementations.
-Comments are designed to appear anywhere in the file. The first 
-character in the line must be a #.
-
-:version  Currently 1.1 is the only supported version.
-           Version 1.2 is in review.
-:units    Currently there are three supported units:
-           mass, length and angle. Mass is not used by many systems.
-          These units are optional and can appear in any order. The 
-           :units keyword is optional. If it appears then there must be 
-           at least one unit defined. The defaults are 1.0 for numeric 
-           fields and the angle default is degrees.
-          The units are interpreted by multiplying the relevant data 
-           directly on readin.  E.g. If the length unit is 2.54 then all 
-           incoming translation or length values should be multiplied by 
-           2.54. This is also the case for the amc file. Any 
-           translations or length values must be multiplied by 2.54.
-          This allows direct scaling of the skeleton and it's motion.
-:documentation
-          This field takes comments and doc which will typically allow
-           the user to uniquely identify this skeleton from any others 
-           and make it easy to ensure that only related .amc files are
-           used with it.
-:root     This defines the base location and orientation of the entire
-           skeleton.  All motion is relative to this point.
-          Typically the root is located at the origin and oriented along
-           the z-axis. However this may not always be the case.
-          The axis field defines the order of rotation of the 
-           orientation data. The order is equivalent to the dof field in 
-           the bonedata and defines the order of evaluation as well as 
-           the order of values in the amc file.
-:bonedata 
-          This section holds all the data for each bone. The data is in 
-           global space and is designed to be human readable.  E.g. You 
-           do not have to interpret the hierarchy to determine which 
-           direction a bone is pointing.
-          The data for a bone is delimited by begin/end tokens.
-          The data needs to appear in the following order.
-               id which is optional 
-               name, direction, length, axis appear next.
-               dof and limits appear next.
-              The remaining items are optional:
-               bodymass, cofmass may appear next.
-               vendor specific options may also appear at this point.
-          The numeric id is optional. It allows systems to refer to the 
-           bone numerically rather than by name. If supplied, it must be 
-           unique.
-          The name string must be unique and preferably follow a naming 
-           convention. One is mentioned below. This name is used in the
-           hierarchy and presumably by the target animation system to
-           help the user.
-          The direction is the normalized direction vector of the bone.
-           It is always a triplet in xyz order.
-          The length and the direction when combined with the hierarchy 
-           will allow you to build a correctly oriented/positioned stick 
-           figure skeleton. The only thing missing is the orientation of 
-           the local coordinate systems for each bone.
-          The axis defines the local coordinate system for each bone. It
-           is in two parts. The xyz triplet of rotation offset values, 
-           and a token representing which order to evaluate those 
-           values.
-           This represents an offset from the global coordinate system.
-           See the later section on local coordinate systems to see how 
-           to use these values.
-          Bodymass and cofmass are used by some systems in determination
-           of rotational inertia's.  They are here as an example of how
-           new keywords can be added by specific vendors.
-          All unrecognized keywords should be ignored.  I.e. Ignore lines
-           of data until you find a recognizable keyword.
-          The dof field defines which axes the bone can move in, what 
-           order they should be evaluated in and the order the data will 
-           appear in the amc file.
-          The limits must follow the dof. Each dof token has an 
-           associated limit. inf stands for infinity. They are in 
-           lower/upper limit pairs grouped by parenthesis and separated 
-           by spaces.
-          Dof specification allows for xyz translation and rotation as 
-           well as movement along the bone ("l") . This movement is 
-           translation not scaling data and corresponds to stretching 
-           the skin.
-          Some bones may not have any motion associated with them. In 
-           this case there will be no dof or limits fields. This bone is 
-           almost certainly being used to place the following bone's 
-           rotation axis in a useful location. We refer to this as a 
-           dummy bone.
-          Systems which do not implement dof limits may ignore them. If 
-           they do they should use reasonable defaults in their files.
-          The limit information should not be used to clip data from the 
-           amc file. The data in the amc file has been preclipped.
-          Limits are there to aid the animator and help to define the 
-           range of motion of individual bones.
-          If a skeleton is designed to work with positional data then 
-           only the xyz translation dof's will be specified. The 
-           vendors system will then have to offer Inverse Kinematic 
-           support to solve the rotational issues.
-:hierarchy
-          This section defines the hierarchical relationships between
-           the bones.  The motion in the .amc file is defined in terms
-           of this hierarchy.
-          This data is delimited by begin/end tokens.
-          The first entry in a line is the parent. Subsequent bones are 
-           the direct inferiors of that parent.
-          The root node is the first entry. It is the special case as it
-           is a node and all the other entries are bones.
-          The parent on a line must have been referred to as a child on
-           a previous line.  The only exception is the root which must
-           always come first.
-
-:skin     The skin is followed by one or more filenames on separate 
-           lines.
-          These filenames refer to skins that fit on that skeleton.
-          For example, you might have a low resolution box figure used 
-           for scene blocking and animation testing, as well as a medium 
-           resolution skin for better animation refinement once the 
-           motion is blocked in. You might also have a high resolution, 
-           fully mapped skin for use in the final render.
-          How these skins are precisely linked to the skeleton is left 
-           to the individual vendors to define. However simple 
-           manipulations of the skin are easily defined if collections
-           of faces are named after the bones they are associated with.
-          For example: The Amcplayer software distributed by Acclaim
-           uses a Wavefront format skin object with the face groups
-           named exactly the same as the bone names.  On reading in the
-           skin object these face groups are attached to the bones.
-           Subsequently the skin moves exactly as the bones do.  There
-           are no soft deformable skins in the Amcplayer.
-
-Additional vendor specific keywords may appear after the :skin keyword.
-Before vendors add any new elements to the file definition please 
-contact Acclaim ATG. Vendor specific keywords or tokens should start 
-with the vendors name or acronym.
-
-Local Coordinate Systems.
-
-          If the local axes were drawn at the bone's starting location 
-then the axis value represents the xyz rotation required to align the 
-global and local axes. The end result is that a 10 degree rotation about 
-the x-axis, as defined in an amc file, would result in a 10 degree 
-rotation around this offset local coordinate system.
-          There are two ways to interpret this value based on whether 
-your system uses a local system or works everything out around the 
-origin and then transforms it out to the bones perceived position. If the 
-former then the axis value defines the offset for your local coordinate 
-system and at evaluation time you simply rotate the bone the required
-value, taken directly from the amc file, about the local coordinate 
-system.
-     If you work everything out in global space and then transform the 
-resulting body out to the bone's location then you need to construct an 
-inverse matrix representing this offset and premultiply the rotation 
-found in the amc file to get the rotation about the global system.
-Exactly how you do this is dependent on the internal matrix 
-representation in your system and whether you are pre or post-
-multiplying your transformation matrices. There is test data available 
-to aid you in setting up these software routines.
-
-     Some systems do not allow arbitrary rotation orders. In this case 
-you will need to simulate them. Independent rotation order can be 
-simulated by having three (maximum) zero length bones at the same 
-location each with a single dof. However this same system will confuse 
-users if they are trying to layer Inverse kinematic data over motion 
-captured data. ( Due to the difficulty of selecting the precise axis).
-Correct implementation of independent ordering for motion captured data 
-is beneficial.
-     If a system suffers from this then it is possible to define at 
-capture time a specific rotation ordering for the root and bones.
-Vendors should inform their clients if this is required or if a 
-particular ordering is beneficial.
-
-Bone Naming Conventions:
-
-    This section details the naming conventions used by the Acclaim 
-process. Individual vendors can choose to use this system if they wish.
-If not then vendors should be aware that bone names can get quite long 
-and should allow for this in their systems.
-    The naming convention is necessary for two reasons, neither of
-which may concern a specific vendor:
-
-     - To easily identify a given bone by its name.
-     - To enable automatic mapping of motion data to arbitrary skeletons
-          using Acclaim drivers or vendor specific drivers.
-
-Naming:
-     There are two conventions the second is a short form.
-      They can be mixed.
-     Bone names are case insensitive but should be lowercase.
-     Bone names have no spaces in them.
-     The Class is optional. If not included it defaults to h.
-     Words in names are separated with underscores. 
-     Bone names ending with underscore number (_1) indicate that there 
-      are multiple segments which motion is divided across.
-      (I.e. h_torso_1) 
-     In the case of multiple limbs or digits use a segment number, 
-      spelled out. (I.e. L_finger_one) 
-     If there are multiple bones in a segment that require individual 
-      motion data then use a position indicator. (I.e. L_up_finger_one)
-
-Syntax:
-     class_side_position_bone_segment_division 
-Class:
-     h     - Human class of naming.
-Side:
-     left  (L)  - Bones on left side.
-     right (R)  - Bones on right side.
-Position:
-     up    (u)  - Bones that are closest to torso or oldest 
-                  ancestor.
-     mid   (m)  - Middle bones.
-     low   (l)  - Bones that are furthest from torso.
-Bone:
-     root                 not a bone at all but the root node of
-                           the skeleton.
-     head 
-     neck 
-     shoulder    (shld)
-     torso       (trs)
-     waist       (wst)
-     hip 
-     leg 
-     foot 
-     toe 
-     toes                 use when modeling all toes together.
-     arm 
-     hand 
-     finger      (f)
-     fingers     (fngs)   use when modeling all fingers
-                           as a single unit.
-Segment:
-     dummy             use if this bone is only used to position the
-                        next one.
-     one         (on)  use when dealing with multiple segments of the
-     two         (tw)   same type.  If numbering toes, fingers
-     three       (th)   (finger_one = thumb, tone_one = big toe)
-       "          "
-
-Division:
-     1                 A number at the end of a bone name indicates 
-     2                  that a set of angles will be shared amongst 
-     3                  the bones. (E.g. the torso or neck) 
-     4                  Start numbering with the oldest ancestor.
-     "
-
-Examples:
-     h_waist 
-     h_torso_1           Torso closest to waist. Rotational data 
-     h_torso_2            is spread across these bones.
-     h_left_up_arm       Left upper arm 
-     h_L_fingers         All left fingers 
-     h_L_finger_one      Thumb 
-     h_left_up_finger_one     Segment of thumb closest to hand.
-     L_l_toe_th          Last bone on the third toe on left foot.
-                    (One with the nail) (fully contracted name)
-
-Example:
-     - human skeleton showing hierarchical nature and naming. (no
-individual fingers)
-
-      root                     Root node of skeleton 
-       h_waist                 first joint in back 
-         h_torso_1             These torsos divide one value evenly 
-           h_torso_2           amongst them all.
-             h_torso_3 
-               h_torso_4 
-                 h_torso_5 
-            h_left_shoulder    the shoulders branch off here.
-              h_left_up_arm 
-              h_left_low_arm 
-              h_left_hand 
-              h_left_fingers 
-            h_right_shoulder 
-              h_right_up_arm 
-                h_right_low_arm 
-                  h_right_hand
-                    h_right_fingers
-            h_neck_1                the neck has its rotations broken
-              h_neck_2               over two bones
-                h_head
-       h_left_hip 
-         h_left_up_leg 
-           h_left_low_leg 
-             h_left_foot
-               h_left_toes 
-       h_right_hip 
-         h_right_up_leg 
-           h_right_low_leg 
-             h_right_foot
-               h_right_toes 
-       h_tail                       for humans in the News of the World.
-
-
-The Motion Data File format. (.amc)
-
-    Acclaim's motion capture data is delivered in the amc file format.
-This motion data is tied to a particular skeleton or asf file. Currently 
-the amc file has a single format. There are three more formats in review 
-that extend the usefulness of the amc file by generalizing it. This 
-document only discusses the :fully specified format.
-
-   The format is very simple. Comments at the top followed by the 
-format identifier. Then the data is grouped by frame. First the frame 
-number and then each bone name followed by the values associated with 
-each dof token in the corresponding dof line in the asf file. The bones 
-are in the same order for every frame. The bone name is verbosely 
-printed for every entry.
-
-The File format:      (text)
-
-# comments. date, which skeleton this data belongs to, etc.
-#
-:fully-specified 
-1
-root 12.0 33.0 45.0 0.0 90.0 45.0 
-h_torso_1 0.0 0.0 0.0 
-h_torso_2 0.0 0.0 0.0 
-h_right_up_leg 14.0 17.23 0.0 
-h_right_low_leg 22.5
-  :
-  :
-2
-root ... (6 values) 
-h_torso_1 ... (3 values)
-  :
-  :
-
-Notes:
-     The comments are indicated by a # character and may only appear at 
-      the head.
-     The format identifier is a keyword and starts with a colon 
-      character. (:) 
-     Values are in the units defined by the asf file. In the above 
-      example the rotations are in degrees.
-     All the bones with dof definitions in the asf file are represented 
-      in the amc file. The order is unimportant. However on successive 
-      frames all the bones will be in the same order. None will be 
-      missed.
-     For each bone there are one or more values following it.
-     The order and number of these values are defined by the order and 
-      number of tokens in the dof entry in the asf file.
-     E.g. For bone h_right_up_leg the dof entry might read:
-                   dof rz ry rx 
-          The entry in the amc file will have 3 values following the 
-           bone name. These entries will be in the order rz ry rx.
-          For the bone h_right_low_leg the dof entry might be:
-                   dof rx 
-          In this case there will be a single number following the bone
-           name.
-     There is no delimiter to indicate the end of file or how many
-      frames of data are in the file.
-
-These and other issues are addressed in the new formats for this file 
-currently under review.  The format identifiers for these formats will
-identify them.
-
-
-Positional only systems.
-
-     A number of motion capture systems use position data to describe 
-the location of each joint in a hierarchy. These systems can use the asf 
-and amc formats as well. The only difference will be in the dof 
-specification where all the tokens will be translational rather than 
-rotational.
-     This raises a point for vendors. You may want a preprocessor to 
-identify whether a given asf file is positional or rotational in nature.
-You can then inform the user as this will affect the kind of tools they 
-will need to process it.
-     Depending on your implementation you may want to ensure that, apart 
-from the root, all of the bones have the same dof type For example it 
-may be a constraint in your system that no length changes are allowed, 
-or you might allow length changes but disallow a mix of rotations and 
-pure translations on a bone.
-     The preprocessor could also help you to determine whether you 
-should be switching an inverse kinematic solution on as a default.
- 
\ No newline at end of file