temporary
`field slicing though the environment. This uses a
`union
`between a
`very
`transparent object,
`such as
`an
`elongated cylinder,
`and the environment
`in which the
`object
`takes precedence over
`the environment. The part of
`the
`environment
`inside
`the
`transparent
`object
`is
`temporarily removed. while the faces corresponding to the
`intersection
`between
`the
`object's
`surface
`and
`the
`environment
`takes on
`the attributes of
`the environment.
`This gives the appearance of a force field moving through
`walls,
`for example. The second technique provides an x-
`ray effect.
`It differs from the force-fieid effect only in one
`aspect:
`rather
`than remove the portion of
`the environment
`that
`is
`inside the transparent object,
`these faces are also
`made transparent. Thus, one can look though walls while
`retaining the sense that
`the wall
`is
`still
`there (see color
`plate).
`the use of shadows.
`is
`A more traditional visual effect
`Our current method constructs
`shadows
`for each object
`independently. This
`is
`achieve
`by
`creating
`shadows
`volumes
`for each face in priority order and adding these
`volumes
`to the object-tree [Naylor 92b]. This
`transforms
`what were formerly out-cells
`into partitioned regions
`that
`are homogeneous with
`respect
`to visibility of
`lights,
`visibility being
`an
`additional
`property
`of
`a
`region.
`Currently. each light
`is assigned one bit
`to indicate visibility
`of that
`light. When trees are merged, shadows are cast onto
`other objects by classifying the faces of one with respect
`to
`the other
`tree. This only requires extending the normal
`tree
`merging process to maintain the visibility property. So for
`example, whenever
`the recursive process reaches a cell,
`the
`visibility of a cell
`is
`transmitted to the other operand by
`performing an "and" operation between the cell‘s visibility
`field and those of the other operand.
`
`References
`
`[Fuchs, Kedem. and Naylor 80]
`H. Fuchs, Z. Kedem, and B. Naylor, “On Visible Surface
`Generation
`by
`a Priori Tree
`Structures,“ Computer
`Graphics Vol. 14(3), pp. 124-133,
`(June 1980).
`
`[Naylor, Amanatides and Thibault 90]
`and William C.
`Bruce F. Naylor,
`John Amanatides
`Thibault,
`"Merging BSP Trees Yields Polyhedrai Set
`Graphics Vol. 24(4), pp.
`Operations", Computer
`ll5—i24,
`(August 1990).
`
`[Naylor 92a]
`"interactive Solid Modeling Via
`Bruce F. Naylor,
`Partitioning Trees". Proceeding of Graphics Interface ,
`pp. 11-13,
`(May 1992).
`
`[Naylor 92b]
`image
`Tree
`“Partitioning
`Bruce
`F. Naylor,
`Representation and Generation from 3D Geometric
`Models", Proceeding of Graphics
`Interface (May
`1992).
`
`[Naylor 93}
`"Constructing Good Partitioning
`Bruce F. Naylor,
`Trees", Graphics Interface '93, Toronto CA, pp. 181-
`191, {May 1993).
`
`fog color occurs
`total
`By setting the fog parameters so that
`the presence of
`the
`at
`(or slightly before)
`the far—plane,
`far-plane is effectively obscured. We use this as a simple
`mechanism for maintaining a
`target
`frame rate of,
`for
`example. 10 frames per second. Whenever
`the frame rate is
`too slow we bring the far—plane closer
`to the viewer at a
`rate determined by the frame rate deficiency. So if one
`turns the corner from a simple to a complex view,
`the fog
`rolls in over
`the next dozen or
`so frames until
`the frame
`rate is
`restored. Similarly, we move
`the far-plane away
`when the
`frame
`rate will
`allow this. Both of
`these
`movements are constrained by min and max values.
`
`Collision Detection in Large Environments
`
`is often
`it
`in the design of entertainment applications,
`required to know whenever
`some moving object collides
`with the environment or with some other object. Such
`collisions can be detected by merging the partitioning tree
`representing an object with a
`"model-tree", whose initial
`value is
`(a copy of)
`the environment-tree. Since each tree
`can be
`interpreted as
`a hierarchy of convex bounding
`volumes, merging two trees is simply merging together
`two
`hierarchies of bounding volumes
`in a
`top-down (largest-to-
`smallest)
`and
`recursive manner. Whenever
`the
`region
`containing a subtree of one tree is found to not
`intersect a
`region
`containing a
`subtree
`from the other
`tree,
`no
`comparisons between the
`contents of
`those two subtrees
`need be made. Empirically,
`this
`seems to happen around
`50-75% of the time. This is, of course,
`the mechanism that
`reduces the computation to be generally less than O(n2). In
`fact, when the objects are sufficiently separated so that
`the
`first bounded/finite regions in each tree do not
`intersect,
`then the computation can be done in 0(1), and is analogous
`to testing two bounding volumes for
`intersection.
`Since the tree has cells labeled as being in-cells or out»
`cells, collisions occur whenever one of the operands in the
`recursive process
`reaches
`an
`in-cell while
`the
`second
`operand is either an in-cell or a subtree containing in-cells.
`For each in-cell, we maintain an identifier field (an integer)
`which can be used to identify the entity with which the
`collision is occurring. We also maintain identifier
`fieids at
`each internal node which is
`set
`to the identifier at
`the in-
`cells of
`its
`subtree whenever
`they
`are
`all
`the
`same;
`otherwise it
`is null. This permits extracting the identifier
`without descending the entire subtree, which it essential
`for
`obtaining
`sub-linear
`performance. Each
`pair
`of
`identifiers
`is
`added to a collision report
`list. which is
`maintained in sorted order
`to avoid adding duplicates.
`
`Visual Effects
`
`A number of special effects appropriate for entertainment
`applications can be achieve efficiently using tree merging
`as
`the basic operation. Oneiclass uses
`traditional
`set
`operations. We have used subtraction to blast holes in walls
`and buildings
`as
`a
`result of
`firing a gun,
`as well as
`to
`simulate tunneling with a drill. One important aesthetic
`consequence of
`this
`is not only the simulation of
`these
`effects, but also the complex and unexpected geometry that
`is created. Such user generated variety reduces the burden
`on a game designer
`to always meet
`the desire for new
`experiences; here the user gets
`to participate is creating
`hislher own variety.
`In principal,
`the other
`set operations,
`union,
`intersection and
`symmetric difference,
`could be
`employed to modify the environment
`in interesting ways.
`Another approach we have developed is
`to combine
`transparency with tree merging to create two new effects
`that only temporarily modify the environment
`(usually for
`only one frame). One of these creates the effect of a force
`
`BUNGIE - EXHIBIT 1006 - PART 8 OF 14
`_
`
`108
`
`BUNGIE - EXHIBIT 1006 - PART 8 OF 14
`
`

`
`Of Mice and Monkeys:
`A Specialized Input Device for Virtual Body Animation
`
`Chris Esposito
`Virtual Systems Group
`Boeing Computer Services
`
`W. Bradford Paley
`JueyChong Ong
`Digital Image Design, Inc.
`
`example, a rotation at the hip that brings the knee up and
`closer to the chest will change the allowable joint rotation
`limits at the knee so that the knee is forced to flex as the
`thigh is raised.
`Several kinds of devices have been used to interactively
`control the posture of a human model. One of these is the
`ubiquitous mouse, which has been used in the Jack system
`from the University of Pennsylvania [1], and the Safework
`system from Genicom Consultants [2], to name two of several
`available systems. In these systems, some portion of the
`body is selected with the mouse and then interactively
`dragged around the screen following the mouse, as far as the
`relevant joint limits will allow. In the Safework system, for
`example, there are seven "handles" that are the entry points
`to the inverse kinematics system. Once one of these handles
`is selected, all translation of the handle and the associated
`joints and segments is done in the plane of the screen,
`regardless of the orientation of the figure. Similar techniques
`are used in computer animation software (e.g., Wavefront's
`Kinemation).
`
`The benefits of being able to manipulate human models in
`virtual environments are sufficiently great that these systems
`are a success, despite some of their difficulties. The core
`problem is that the desired manipulations are inherently 3D
`with many continuous—valued degrees of freedom, but the
`manipulator used is a 2D device with 2 continuous-valued
`degrees of freedom (x,y position) and 1 discrete—valued degree
`of freedom (button state). Jacob & Sibert [3] describe this as a
`mismatch between the perceptual structures of the
`manipulator and perceptual structure of the manipulation task.
`They have demonstrated that for tasks that require
`manipulating several integrally related quantities (e.g., a 3D
`position) a device that naturally generates the same number of
`integrally related values as the task requires (such as a
`Polhemus) is provably better than a 2D positioning device
`(such as a mouse).
`
`The task of interactively manipulating a human figure is more
`complicated than the positioning task described in [3] in two
`ways. First, there is a much larger number of degrees of
`freedom to choose from, and it is often desirable to
`manipulate several of them simultaneously. Second, the
`"posture space", or set of possible postures, is continuous
`and Euclidean in most places, but has pockets of unreachable
`areas that represent postures that a human cannot normally
`do.
`
`1.2,‘ Related Work
`,/ ‘
`There are numerous examples of so-called "waldo"
`devices (the term comes from a Robert Heinlein story [4}),
`which are used to control a device it mimics. The Exos
`Dextrous Hand Master is an exoskeleton worn over the hand
`and wrist, designed initially for the teleoperation of
`robots.[5] Jim Henson's muppets are waldo-controlled, and
`include a computer - generated character named Waldo C.
`
`109
`
`Abstract
`
`This paper discusses the motivation, design,
`implementation, and some sample applications of a new
`input device, called the Monkey”, that can be used for real-
`time control of digital human models.
`
`1. Introduction
`Software models of realistic human figures are useful
`in a wide variety of areas, from TV commercial animation to
`human factors analyses of reachability and maintenance
`procedures in aircraft design. A common requirement across
`all of these areas is the quick and easy manipulation of the
`figure into desired postures for keyframes or through motion
`sequences for interaction with the surrounding environment.
`This paper describes a new input device, called the Monkey,
`that has been designed to make these manipulations faster and
`easier than they have been, discusses several of the issues
`surrounding it's rationale, design, and prototype
`implementation, and briefly describes some of the
`applications of this device that are in progress.
`
`1.] Motivation
`Realistic human figures are complex structures that
`have many joints, with each joint having I or more
`rotational degrees of freedom. Each of these degrees of
`freedom has an associated constraint or limit that determines
`how far the associated joint can flex around the specified axis.
`To further complicate matters, some of these constraints
`interact (in a non—linear way) with other constraints. For
`-::?:
`
`l l l l
`
`Chris Esposito (chrise@atc.boeing.com)
`Boeing Computer Services
`PO Box 24346, MS 7L-48
`Seattle, WA 98124
`
`W. Bradford Paley (brad@didi.com)
`JueyChong Ong (ong@didi.com)
`Digital Image Design, Inc.
`170 Clarernont Ave., Suite 6
`New York, NY 10027
`Monkey is a trademark of Digital Image Design, Inc.
`
`Permission to copy without fee all or part of this material is
`granted provided that the copies are not made or distributed for
`direct commercial advantage, the ACM copyright notice and the
`title of the publication and its date appear, and notice is given
`that copying is by permission of the Association of Computing
`Machinery. To copy otherwise. or to republish, requires a fee
`and/or specific permission.
`1995 Symposium on interactive 3D Graphics, Monterey CA USA
`© 1995 ACM 0-89791-736-7/95/0004...$3.50
`
`

`
`Graphic.[6] Dave Sturrnan has also created a "finger—walking"
`puppet controlled with a DataGlove.{7]
`
`Another approach to whole-body control, more sophisticated
`than the mouse, uses a real person instrumented with position
`trackers and a motion capture system that records the person's
`movements in real time. Because these systems usually have
`sampling rates of more than 30Hz, real-time animation is
`possible. The Poihemus Fastrak and the Ascension Flock of
`Birds are two commercially available position tracking
`systems that have been used for this purpose. This approach
`neatly solves the problems mentioned above, and a well-done
`implementation can capture very complex and subtle real-
`time movements that would be difficult to capture any other
`way.
`
`However, current implementations of this approach also have
`problems of their own. The first problem is cost, since a fully
`instrumented body can easily use 10-12 sensors and such a
`system can easily cost $30,000. The second problem, as
`several animators have found, is that it makes a difference
`where on the body the sensors are placed, and the optimal set
`of positions is not obvious. The third problem is that each
`sensor is attached to a central unit by a long cable, and that
`dragging around as many as a dozen cables is sufficiently
`encumbering that this system really requires two people to
`operate, with one to run the motion capture system and one
`dedicated to performing the motion. The fourth problem is
`that the electromagnetic fields used by these systems are
`distorted by the presence of metal in the surrounding
`environment, which degrades the accuracy of the reported
`measurements.
`
`In other systems, the magnetic sensors are replaced with
`reflectors, light sources and high speed cameras which capture
`the reflections as points of light that can be tracked. An
`overview of how these systems are used can be found in I6].
`
`To animate facial features, Williams used a video camera to
`track reflective material attached to an actor's face.[8] These
`reflective spots are then mapped to points on a facial model.
`Commercial systems using this technique are now available.
`In another technique, the VActor uses sensors in contact with
`the skin of an actor to achieve similar results (effectively a
`facial waldo).
`[6]
`
`The above systems wefe designed for the real-ti_me recording
`of animation. Their emphasis is on collecting a continuous
`stream of data. The higher the update rate, the more realistic
`the animation is likely to be.
`
`For non-real-time input of an animation sequence, traditional
`animators have applied a technique of using miniature models
`or armatures that are positioned with varying degrees of
`automation for capturing successive frames of an animation
`sequence. This is known as stop—motion animation. For
`example Tim Burton's ”The Nightmare Before Christmas"[9]
`was animated almost entirely with this technique, each of the
`characters painstakingly positioned by hand for each frame of
`the movie. For Jurassic Park[10], Industrial Light and Magic
`collaborated with Phil Tippett to create miniature dinosaur
`armatures fitted with encoders at key joints. This allowed the
`model to be used by stop—motion animators, but with the
`keyframe data input into the computer animation system.{ll]
`It is important to note that the earliest stages of the work
`described here were done in early 1992, predaling disclosure
`of the completely independent work done for Jurassic Park.
`
`2. A. New Input Device - the Monkey
`The prototype Monkey stands about 18'‘ tall and is
`about 6" wide. The figure can be either freestanding or
`attached to another sensor at the end of a scaffold on a support
`stand. This allows the figure to be rotated in space with
`respect to the stand and then left in that position without
`
`additional support. From head to toes, there are 32 total
`degrees of freedom (1 per sensor) in the prototype Monkey.
`In addition, there are three degrees of freedom for orientation
`with respect to the base. The production Monkey has 35
`sensors, plus 3 additional for the attachment to the stand. The
`Monkey body itself is proportional to a 50th percentile
`North American male body, with deviations only where
`necessary to position the sensors. Additional sources of the
`anthropometric data used in constructing the prototypes were
`[12] and [13].
`
`Since the number of degrees of freedom in the human body is
`greater than the number given above, obviously not all of the
`body joints are instrumented. For example, a single site
`above the pelvis in the Monkey represents the entire spine
`with only three degrees of freedom.. All of the major limb
`joints are instrumented, although the number of sensors for a
`joint varies depending on how that joint moves. Each sensor
`has an associated rotation limiter, set beyond the normal
`range of human motion, that prevents damage to its
`associated sensor. The sensors are loose enough to allow
`smooth motion without excessive effort, but with enough
`friction so that the figure can be put into a posture and stay in
`that posture without further support.
`The rotation sensors themselves use low-noise conductive
`plastic potentiometers which are low cost and provide a
`rotational accuracy of 3 degrees and a resolution of 0.3
`degrees, which is more than sufficient for almost all of the
`expected uses. If more accuracy is desired, then more
`expensive military-grade potentiometers can be incorporated
`without too much effort. The use of potentiometers makes
`this system immune to the magnetic, acoustic and infrared
`interference that degrades the performance of most other
`trackers. The maximum lag per sensor is 2 milliseconds. For a
`given Monkey, there is a fixed relationship between the
`physical position/orientation of a sensor and the value it
`returns, which means that postures are precisely repeatable.
`
`The Monkey also has eight binary inputs. These can be wired
`to foot switches or other binary devices and may help to
`increase productivity or user comfort in two ways: 1) a user
`does not have to go back and forth between the Monkey and a
`mouse or keyboard; 2) users uncomfortable with computers or
`the software user interface do not even have to deal with this
`issue. Several traditional stop motion animators we talked to
`informally were adamant about not Wanting to deal with a
`computer.
`
`2.] From Prototype to Production
`Informal testing and evaluation of the prototypes at
`Boeing, Digital Image Design (DID), and by thousands of
`attendees and passers-by at SIGGRAPH led to a number of
`changes from the prototype to the production models. Some
`of the most important ones are described below. Figure 1 is a
`picture of the production Monkey.
`
`We found that even though there were plenty of places that a
`user could comfortably and effectively grasp the Monkey to
`move it (e.g. the brass links in arms and legs, the
`potentiometers, etc.), these places were not obvious to the
`first~time user. We enlarged the Monkey to be 1/3 human
`scale, and this allowed longer links between joints. We
`machined larger diameter link pieces for both arms and legs
`(eight in all) and put hollowed out sections at the center of
`each one. These sections read immediately as finger-holds,
`and new users need no explanation to make use of them. As
`anecdotal evidence of their effectiveness, no further
`=complaints about it being untouchable have been heard.
`
`We found that the Z-axis clavicle joint was important to allow
`full vertical reach, as it works with the shoulder when
`someone does something like pat one’s head. It was also
`important to animators, because a shrug, a very expressive
`
`110
`
`
`
`
`
`
`
`__.___.._____._______.._.,._,._.._._.:_._...._..»cc".._____T___....j___....._.,-......__.___._..______._
`
`

`
`

`
`gesture, is almost exclusively a Z-axis clavicle rotation. This
`joint was added to the production Monkey.
`
`We added a metatarsal X-axis joint to allow the Monkey to be
`mounted by the feet to a stand or perforated metal platform.
`(The metatarsal joint, and all of the joints in the leg have
`been made strong enough to support the weight of the whole
`Monkey, even standing on one toe.) This kind of mounting
`enables several Monkeys to be used together in a scene
`requiring the interaction of several figures. It also enables
`animators to more fully express a walk cycle, as people shift
`their weight from heel to toe. It also helps experienced stop-
`motion animators to more accurately judge and express
`weight and balance, things recognized as a result of a gestalt
`effect of combining figure and floor.
`
`Adding a stylized, but realistic and asymmetrical, profile to
`the feet and hands helped in two ways. It allowed us to avoid
`putting mechanical limits on the swivel joints because users
`can immediately tell which direction to rotate a limb back
`towards its rest position. In the prototype, the symmetrical
`feet and hands left confusion, especially as to which side of
`the arm was the front. This slight additional
`anthropomorphic nuance also gives the Monkey a much more
`human aspect, subtly enhancing the ability of the user to
`look at the input device itself to sense whether the current
`posture is balanced, comfortable, expressive, or realistic.
`
`The two central pieces, the torso and pelvis links, were
`awkward to move in the prototype. We added a breastplate
`that acts a handle to grasp the torso. Even more important to
`recreating postures involved in walking, lifting, and dancing
`is fluid movement of the pelvis. A permanent handle here
`would inhibit leg movement and interfere with the mounting
`post. Instead we put two holes in the front of the pelvic link
`as a docking site for a removable tool that provides enough
`leverage to move the pelvis with ease.
`
`We did put mechanical limits on the hinge joints to prevent
`over-rotation that could damage the potentiorneters.
`Mechanical stops were more important to implement on
`hinges because in typical use there is much more leverage
`available than there is for swivels.
`
`While even the prototypes had fully variable tension on the
`joints, production Monkeys are more carefully balanced with
`regard to joint tension. The user may change the tension, but
`it is a laborious and non-trivial task that has a large impact
`on usability.
`
`Detachable and individually replaceable wires with strain-
`reliefs were added to lessen the frequency and impact of the
`inevitable pulled cable. Now, a cable will generally just
`unplug if too much tension is put on it; it can easily be
`plugged back onto the potentiometer. Even if it breaks it can
`be replaced immediately, with Monkey controller and
`software running.
`
`A move light was added to the Monkey controller box. This
`light blinks on and off with a frequency directly proportional
`to the speed at which a joint is moving. It gives immediate
`feedback to the user that this specific rotation is being
`interpreted by the controller. This is very useful to test the
`Monkey and controller without having to connect it to a
`computer. It is also a reassuring sign that all is functioning
`well even if a screen update takes several seconds (as it may if
`the Monkey is driving complex rendering or compute-
`intensive constraint systems).
`
`2.2 The Computer-Monkey Interface
`The Monkey is connected to a controller containing
`analog-to-digital converters and RS-232 serial
`communications hardware. The controller implements a
`simple communications protocol for sending and receiving
`
`requests and data between the computer and the controller.
`The controller can be set to filter out data from joints that are
`not of interest for a particular use. LED indicator lights on the
`front panel of the controller indicate power onfoff and data
`sending/receiving.
`
`Protocol Description
`The protocol currently supports 12 commands, with
`each command specified as a 2-byte, unterminated string.
`One of the commands, ‘Set Active Channel Bitmask', also
`takes 5 bytes (40 bits) of unsigned data for specifying what
`channels should report data back. The most significant bit of
`the 1st byte is channel 0. The complete protocol description
`document is available on request from Digital Image Design.
`
`The following commands are available:
`
`0
`0
`
`0
`
`0O0
`
`0
`
`0
`
`0
`0
`
`0
`
`Reset the controller
`Stream mode: Switch to Stream mode and send
`
`posture data continuously
`Stream with Timestamp
`Demand mode: Switch to demand (polling) mode
`Demand: Request a single posture data record
`Demand with Timestamp
`Read the binary input channels
`Set the data channels reporting bitmask - takes 40
`bits of data, l/channel
`
`Set the Band rate: selected speeds are 9600, 19200,
`38400, 5760, and 115200
`
`Obtain the data channels reporting bitmask
`Halt stream mode (implying a switch to demand
`mode)
`Obtain the hardware and firmware version
`information
`
`Controller Data Format
`
`Posture data is returned in a variable length tagged
`record. The first byte indicates the number of data channels
`reported in the record. This is followed by three bytes for each
`channel reported: the first of the three bytes contains the data
`channel number (1-40), and the other two contain the value of
`the channel. Channel values range from 0 through 1023,
`although the resolution is reduced in at the extremes (approx.
`0-100 and 923-1023). Finally, the last four bytes contain the
`timestamp if requested.
`
`All data returned uses only seven hits per byte; the most
`significant bit is used as a phasing bit, where the first byte of
`any record has the phasing bit set, and all remaining bytes
`have their phasing bits cleared.
`
`This protocol, the data format, and the phasing bit
`conventions are similar to those of other
`position/orientation tracking devices. This makes it
`possible to quickly convert or extend existing software for
`one of these devices to control the Monkey.
`Initially, we were concerned about the additional bandwidth
`requirements imposed by the use of a tagged data format. We
`later decided that we could obtain sufficient throughput with
`the tagged format and enjoy two advantages:
`ll). data from each channel need not always be sent in a
`particular sequence, allowing greater flexibility in
`implementing the controller firmware.
`
`112
`
`

`
`2). it allows us to implement differential reporting
`modes in the future to increase throughput; in the
`differential stream or demand reporting modes only data
`channels which have changed by a certain amount set by
`the user will be reported. This is similar to the
`incremental reporting mode found in certain tracking
`systems. However in incremental mode, data is sent only
`if the sensor has changed. In differential mode, "empty"
`records are sent if there are no sensor updates and a
`demand poll or stream request is received. Recognizing
`the difference between a moving stream of data and
`"jitter" oscillations of the analog-to-digital circuitry
`will be an issue to be addressed.
`
`To address the possibility of controlling several characters in
`a shared space, we have designed features into the controller
`that will enable the linking and addressing of multiple
`Monkeys or Monkey—complementary devices in the same way
`that many position/orientation sensing systems allow
`multiple sensors to be used in a shared space. This will be
`beneficial in applications which deal with multiple
`interacting human characters.
`
`Controller throughput
`We informally measured the throughput of the
`Monkey controller (firmware version 2.0) for both streaming
`and polling mode using a simple program which reads,
`decodes and stores a certain number of Monkey data records in
`an array. The program uses UNIX (UNIX is a trademark of
`AT&T Bell Laboratories) read() and write() system calls
`through the UNIX termio interface. gettimeofdayo was called
`before and after execution of the readidecode/store cycle for
`all of the records to determine the elapsed time required to read
`the total number of data records into the array. The program
`was written in ANSI C and run on a Silicon Graphics Indigo
`Elan R4000 computer under a beta version of the IRIX 5.3
`operating system. The serial port speed was 38,400 band. The
`controller is capable of handling speeds of up to 115,200
`baud.
`
`We obtained the following results for processing 400 records:
`
`Polling Mode (38,400 baud)
`
`lrtomfchannelstsmttai Axenmcfmnatehentfise
`
`40
`
`20 (assorted*)
`
`3
`
`(channels 0,1,2)
`
`24.94
`
`47 .90
`
`49.96
`
`Stream Mode (38,400 baud
`
`tlsanfchaaaelsremned
`trials)
`
`40
`
`Axztnraotrenanstsaeltfhze
`
`20 (assortecl*)
`
`3
`
`(channels 0,1,2)
`
`175.56
`
`29.13
`
`53.43
`
`*for each trial, a different set of twenty channels was
`specified.
`
`113
`
`3. Color Plate
`
`The figures on the color plate show how the
`Monkey might be used in computer animation using
`Wavefront Technologies’ Kinemation software. Kinemation
`has a motion capture interface which allows users to write a
`motion capture server interfacing Kinemation with various
`devices (like Ascensi0n's Flock of Birds or Polhemus'
`FasTrak, the Monkey and others).[14, 15]
`
`The photographs show Bob Nicoll of Wavefront
`Technologies posing the Monkey in three postures for an
`animation sequence. After the initial capturing of the three
`key postures, spline interpolation and several constraints are
`applied. Selected frames from the resulting one hundred-frame
`animation are shown next.
`
`4. Future Work
`
`The Monkey and similar devices show promise in
`increasing the productivity and ease of tasks requiring the
`non-real-time specification of body postures. Such devices
`play increasingly important roles as it becomes less and less
`cost-effective or impossible to build a full-size mock-up or
`subject live actors to threatening situations.
`
`The first author is currently engaged in writing a driver and
`integrating the Monkey into an existing human modeling
`system used at Boeing for evaluating human factors analyses
`of aircraft designs. Most of these analyses have to do with
`instrument visibility, part reachability, and validation of
`maintenance procedures on digital prototypes before the
`plane is assembled for the first time. These analyses are
`currently fairly time-consuming to do, but the Monkey's ease
`of manipulation is expected to considerably reduce the time
`required. A series of usability studies is planned to quantify
`the benefits of using the Monkey instead of the existing
`mouse—based system.
`
`DID plans to produce complementary devices that will
`augment the capabilities of the Monkey. For instance, a hand
`is planned for the near future to increase the articulation
`capabilities that would be possible when used in conjunction
`with the Monkey.
`
`DID is also continuing to investigate ways to increase the
`update rate of the Monkey in real applications by finding
`ways to reduce the rendering bottleneck in slower computers.
`The current Monkey server in Kinemation, for example,
`updates all thirty-nine joint rotations at each update
`regardless of whether those joints have been moved. Jittering
`in the analog-to-digital circuitry also causes a nervous
`twitching appearance of the virtual body. Some filtering of
`the incoming data should minimize this.
`
`Current DID research includes developing a way to use the
`Monkey to add more character and expressive movement to
`the relatively flat-looking data that is obtained using motion
`capture devices. This is an important research area for
`animation, as motion capture alone may not satisfy audiences
`looking for interpretation, not mimicry. Rotoscoping was
`considered and discarded by Disney as early as the late 1930s
`for the production of Snow White. [16] Most of the
`experienced animators we have spoken with have remarked on
`the lifelessness of captured data. We intend to generate key
`frames to fit captured data, maintaining the weight and beauty
`of real physical movements, then tweak those key frames
`with the Monkey, bringing the movement back into the
`realm of fantasy.
`Repositioning the Monkey to a previously input or
`computer-generated posture is an important task for some
`uses, especially in animation for adding character to
`relatively flat motion-capture data. This can be done on the
`screen by superimposing a figure in the target posture and one
`
`

`
`following the Monkey. We are of the opinion, however, that
`a display integral to the Monkey armature itself will greatly
`ease this task. Such a display is under development.
`
`with traditional stop-motion armatures. Tony Sinunerman
`pointed out that the Monkey allows posing to continue even
`if a screen update takes several seconds.
`
`5. Acknowledgements
`Jeff Taylor contributed artistry in mechanics for the
`Monkey armature. Genicom Consultants contributed to the
`early discussions about software interfaces and provided
`valuable anthropometric data. Rush Green and Paul Johnson
`from Boeing provided an animator‘s eye view of the Monkey
`specifications. Dan Ling and Tim Skelly in the Research
`Group of Microsoft Corporation provided encouragement and
`suggested more animation requirements. Bill Chernoff from
`Shooting Star Technologies contributed to the protocol
`specification. Eric Leighton gave us a careful, expert
`analysis of the Monkey and descripti