Matt Gough Blog [closed]: practice makes perfect (?)
Wednesday, Nov 10 2004, 01:32
'Movement is a displacement or change of position, even if it cannot be defined as such' - Merleau-Ponty
motion is central to dance, be it sensed, perceived or implied.
this is the issue central to human movement simulation (HMS), at least it should be. with few exceptions HMS research has paid more attention to function (biomechanics) and posture.
the prevailing concept is simple, simulate the way in which the human body works (inverse and forward kinematics, inverse and forward dynamics with a hierarchal skeleton) and motion will be generated as the product of changing posture. this is key framing in three dimensions, where the transition between postures; interpolation is dependent on a single solution (such as quaternions) or the biomechanic construct (kinematics, dynamics).
the problem is that motion generated according to these principles is rarely naturalistic or believable, why else would motion capture be so prevalent. key framing works well in animation because the visual effect of motion is easy to simulate in two dimensions as numerous optical illusions demonstrate. whilst the visual effect of motion can be simulated in three dimensions it still requires accurate physical and transitional modeling.
remember how at the end of a hard ballet class you might start cheating, not faithfully applying ballet technique but making sure it appears that you are. that's simulating the visual effect of motion in three dimensions. an experienced eye (such as your teacher) can tell the difference but otherwise, there is little visual discrepancy.
this is what we do as dancers when learning new movement and techniques, we simulate the visual effect of movement whilst applying our knowledge of somatic function, potential and existing movement skills. it's the application of this detailed knowledge that is missing from current HMS solutions.
the knowledge relating to specific areas, or domains of movement practice are not only detailed but difficult to encode. solutions such as style based kinematics and dynamics have been developed from parameterized data sets (created from motion capture of the specific domain) yet these also suffer from simulating the visual effect rather than applying the physical technique.
animating, performing and teaching movement are very different skills. with HMS the system, or golem (avatar) must be taught how to dance. yet a this teaching must be encoded in manner that can be implemented. This encoding requires a knowledge of movement simulation approaches and solutions.
a common mistake in encoding domain specific knowledge for HMS is taking the 'beginners' approach. the learning curve of a golem is very high, the key is in encoding the application of the technique at the same time as the function. the beginners approach can be seen in solutions where domain specific postures are encoded with little attention to the domain specific transitions (application).
clearly encoding domain specific knowledge requires a high level knowledge in a) the specific domain being encoded and b) the methods by which such data can be encoded and the target system. in most instances this cannot be achieved by a single person, but by two generalists with complementary skills.
of course to fully, and faithfully encode a movement technique requires the golem to have a body capable of said technique. few avatars a modeled in enough structural detail to achieve realistic walking let alone advanced movement practices. areas of the body that require particular attention are the spine, pelvis, sacrum, ankles, feet and toes. i'm not going to explore this in detail here but it's an important issue.
so how is the knowledge encoded so it can be reused? through layered notation. this not only speeds up the encoding process but also enables more 'novice' users to generate motion sequences (it should be remembered that crafting motion is still a skill, some 'technical' knowledge of the simulated domain is still required).
there should essentially be three types of notation that may form multiple layers; raw, abstract and compound abstract. the raw notation should be able to describe all motion. typically the raw notation will be math based with structural references, it need not be entirely human readable / editable but should be formed in such a way that a simple interface may be used create and modify values.
abstract notation is formed from raw notation. this direct abstraction allows for the quick reuse of movement concepts such as the plié in ballet or the fist handshape in sign language. such concepts should not be a part of the raw notation as they are domain specific constructs that would limit it's descriptive and adaptive flexibility. whilst it is tempting to consider them basic movements they are actually compound structures.
compound abstractions may combine raw and abstract notation, multiple abstractions, abstractions and compound abstractions or multiple compounds. raw notation may used to generate specific modifiers. a set port de bras would be defined in compound notation.
the advantage of this layered structure is that the detail in each level of abstraction is maintained allowing discrete changes to be retrospectively applied. this also helps to define stylistic constraints within a domain, therefore ballet can have styles such as:
these may be defined after the construction of the basic domain, with specific notations for each style. the same is true for other movement practices such as T'ai Chi Ch'uan, styles include:
conventions could be specified as domain:style:abstraction. the need to define style within the notation highlights how descriptive the raw notation must be, style can be identified by; posture, orientation, alignment, transition and application. these parameters should not only be defined in the raw notation, but be implemented in the simulation engine.
the notion of 'avatar independent notation' is currently very popular. Taking the position that golems (avatars) a time consuming to produce, a notation should be designed for use with any avatar. this is not possible to two reasons:
in specifying a notation and encoding motion you define the requirements of the avatar. for example, if you encode sign language your avatar must have hands, fingers, elbows etc capable of performing the movement all movement practices are based on a default set of techniques that are adapted to individual capabilities, and application. alignment within transitions and postures are variable within the parameters of the technique or visual effect required.
thirdly, (as i commented earlier) not all golems have the correct structure to apply movement techniques correctly. for example 'turn out' requires a sacrum articulating with each half of the pelvis. in most avatars this three segment mechanism is fused into a single segment. you may have observed that digital ballet dancers that don't use motion capture have poor degage, this is partly due to single segment pelvic girdles.
i believe that notations should be designed for a default avatar, this allows the basic encoding to be adapted for other avatars (semi) automatically. when re-mounting a dance work you look for dancers that can fulfill the needs of the choreography and adapt the work to them where required. this is the model i suggest for the digital space. the this forced adaptation of the notation would also result in a 'individulal' style for each golem. in multi golem simulations this would increase the realism of the scene.
the HMS solution i am working on is based on my dance practice, particularly my improvisation practice (including CI). the detailed study of the fundamentals of human movement and the cognition of that movement directly apply to simulation design. i may expand on specifics later, but for now...
thank's for reading
Filed by Article19 at 1:32 PM | 
Stumble It!