HyperMatter Overview

HyperMatter is a physically based software library for modelling the dynamics of rigid, quasi-rigid and soft, highly deformable objects and materials.

The strength of HyperMatter derives from its very accurate and stable elasticity model. Unlike most other approaches, it does not use linear springs. Instead it is derived from (a unique 6D-variant of) the equations governing the classical theories of elasticity and continua.

In real life, the dominant property that determines the dynamical behaviour of objects is their elasticity. When a constraint is imposed on part of an object, causing a local deformation to take place, it is the elastic restoring forces that develop which largely determine the reaction forces, and hence the resultant motion of the object. Rigid body motion is physically impossible. Even objects that appear to be hard and rigid deform very slightly when they interact with each other, or respond to external forces and constraints.

An accurate elasticity model is therefore crucial. Even smaller, more subtle deformations can be very revealing about an object, and greatly enhance the sense of materiality and realism. The eye can easily discern the difference between realistic motion and motion that merely purports to be realistic.

HyperMatter is also very 'stable'. HyperMatter objects can suffer large and violent deformations. The stability of HyperMatter means that it can be used as a reliable foundation for more complex physically based environments and scenarios. It is also fast, and allows 'complete' and intuitive control of objects during playback.


Geo Objects and Hyp Objects

HyperMatter operates on its own physically based HyperMatter objects (or 'Hyp objects', for short). A Hyp object is a 3D mesh type object shaped to roughly match the shape of the user-geometry that it controls.

A Geo object is HyperMatter's internal representation of a user-geometry object. Essentially, a Geo object consists of a vertex list, and possibly a face list, and two or three transforms used to define certain special configurations of the Geo object. HyperMatter operates on its own Hyp objects directly, and on Geo objects either directly or via their controlling Hyp objects. At any instant during playback, the resultant updates of a Geo object's individual vertex positions or transforms can be copied back onto the corresponding user-geometry.


A Hyp object can either be created on its own, and then later associated with a Geo object, or it can be created directly from a Geo object. In either case, a 'material association' is established between the Geo object and its controlling Hyp object, that binds each vertex point of the Geo object to a unique material volume element of the Hyp object. After each physical time-step, the (new) current configuration of the Geo object vertex points can be 'interpolated' from the current state of the Hyp object, and these values then copied back onto the original user-geometry, resulting in physically based motion of the latter.

In most cases the material association between a Geo and Hyp object is 'static'. The Geo object does not move relative to its controlling Hyp object deformer. In these cases the material association between the two would need to be established only once, before playback takes place. But there are cases where a Geo object does move relative to its controlling Hyp object deformer. For example, Geo 'eye' objects might move relative to a deforming Hyp 'head' object. In such cases, the material association must be re-computed during playback, after each frame.

We call the combined operation of re-computing the material association between a Geo object and controlling Hyp object, followed by interpolation of the Geo vertex points, a 'soft-transform'. We say that the (moving) Geo object is 'soft-transformed' from, or relative to, the Hyp object. In the simpler and more commonly used 'static' case we simply say that the Geo object is 'interpolated' from the Hyp object (even though, of course, interpolation takes place in both cases), and reserve the term 'soft-transform' for the 'dynamic' case, where the Geo object 'moves' relative to its Hyp deformer (even though, of course, the 'static' case can be regarded as a special case of the more general 'dynamic' case).


Basic HyperMatter Scenario

Physically based motion of a user geometry object (polygonal or spline surface) is achieved by first creating a 'Geo' object, which is HyperMatter's internal representation of user geometry. A Hyp object that roughly matches the shape of the Geo object (and hence the user geometry) is then created. An appropriate set of material attributes are ascribed to the object, and its Initial state is defined.

The Initial state of a HyperMatter object is the state from which motion of the object proceeds. Physically based motion is achieved through an internal 'time-stepping' function, which, starting from its Initial state, progresses the current state of the Hyp object from one instant to the next. This process determines the subsequent 'natural' motion of the Hyp object.

The natural motion of a Hyp object can be 'constrained' using built-in constraint functions, so that it can be made to exhibit some form of desired motion or behaviour. The HyperMatter constraint functions act on 'parts' of Hyp objects, which are (default or user-defined) sets of Hyp object vertex points. For example, a constraint might 'fix' part of a Hyp object in space, or attach it to some other moving object, over some specified period of time. HyperMatter includes a compact set of primitive constraint functions that allow complete control of Hyp objects at all times.

After each frame of physically based motion, the new state of the Geo objects can then be 'interpolated' from the current state of their associated Hyp objects, and the new Geo vertex positions copied back to the original user geometry objects, thus resulting in physically based motion of the latter.

It is perhaps worth mentioning here one crucial difference between rigid motion and elastically deforming motion:-

In the former case, if a (possibly key-framed) geometry object is seen to tumble through space or spin about an axis, for example, then it does so because it is explicitly transformed each frame into a new configuration, via the rigid-body transforms applied to it. But in the latter case, where the object moves 'physically', the object (approximately) maintains its shape on account of the elastic forces within it. It is the elastic forces that hold the object together, as an 'object'. If the elastic forces were 'zero' then its vertices would just drift apart. It could not be sustained as an object. It can be easy to overlook this fact when you see a 'physical' object moving through space.


Parts and Constraints

Left to themselves, HyperMatter objects 'do their own thing'. Their 'natural' motion is determined by their material properties (including 'gravity'), their inertia (cf: Newton's 1st law of motion) and by the classical theories of elasticity and continua. An unconstrained object would simply 'fall through space', possibly spinning and deforming as it falls.

HyperMatter constraints operate on 'parts' of Hyp objects (pre-defined sets of Hyp object vertex points). A constraint is imposed on some part of a Hyp object whilst the rest of the object is free to move and deform naturally. Parts are referenced by unique integer identifiers. The first three parts of a Hyp object are system-defined. Part 1 of a Hyp object contains 'all' vertex points belonging to the object. Parts 2 and 3 contain the boundary and interior vertex points respectively. Other parts can be defined by the user.

For example, HyperMatter includes methods for getting and setting the positions, velocities and angular velocities of parts of Hyp objects, for 'rigidifying' parts of Hyp objects, and various means of 'fixing' or 'attaching' parts of Hyp objects, either in space or relative to (possibly moving) Geo objects (cf. 'animatronics' type methods of control).

The 'Fix' constraint can be used to (rigidly) fix in space the individual vertex points belonging to a part, or relative to a moving Geo object. The 'FixPos' constraint is similar, but instead of fixing the points individually, fixes the centre of mass of the part, either in space or relative to a moving Geo object, whilst allowing the part to otherwise deform and/or rotate naturally. Finally, the 'FixOri' constraint fixes the orientation of the part, either in space or relative to a moving Geo object, whilst allowing the part to otherwise deform and/or move laterally.

These Fix constraints are extremely useful in many contexts, either for controlling the primary motion of a Hyp object, or maybe just to add a little extra control as and when needed, or just to prevent part of an object moving in response to other constraints. Our BearHead example scenes make much use of these constraints.

There are also constraints for enabling 'contacts' and 'collisions' between Hyp objects, or involving Geo objects, as well as regular 'walls' and 'planar' constraints, and various means for 'gluing' together and 'ungluing' Hyp vertex points, and a small number of other miscellaneous constraints.

From these more simple constraint primitives the user can construct their own higher-level constraint mechanisms. HyperMatter thus relieves the programmer from the difficult, time-consuming and often frustrating task of creating base objects and constraints, allowing the programmer instead the freedom to concentrate on higher-level principles and design criteria.


HyperMatter Physical Components

The concept of a HyperMatter 'physical component' is based closely on that of a mechanical component in real life. A physical component is a composite object, built from Hyp object(s) and other simpler, lower-level components, that is designed to fulfil a specific functionality.

A component object manages the creation, constraint handling and destruction of its constituent objects, as well as any other special operations, and, crucially, is designed to be 'attachable' to other components and Hyp objects. Examples of (first-order) HyperMatter components are 'rotorunits' and 'motorwheels' :

A 'rotorunit' is comprised of two unit-cube HyperMatter objects that (roughly speaking) are constrained at each instant to be rotated relative to each other by a specified target angle.

A 'motorwheel' is comprised of two HyperMatter objects, namely a unit-cube 'motor' HyperMatter object and a 'wheel' HyperMatter object, that are constrained at each instant to rotate relative to each other with an angular velocity that is computed internally subject to various input parameters, such as the current accelerator (or brake) pressure and gear position, and subject also to (pre-set) 'maximum' velocity and acceleration limits.

Components can be 'attached' to each other, or to regular Hyp objects, simply by aligning them appropriately and applying a special built-in attachment method. (By convention, higher-level components are responsible for managing the attachments of their constituent, child components and/or Hyp objects, using HyperMatter 'glue-bindings' applied to corresponding Hyp object vertex points. HyperMatter 'glue' constraints can then be automatically applied internally, during time-stepping.)


From these two basic first-order component types, in conjunction with regular HyperMatter objects, can be built various 'second-order' components, designed, for example, to simulate the dynamics of motor vehicles and simple 'machines' and 'contraptions'. HyperMatter's 'vehicle' components are examples of such second-order components.

HyperMatter vehicles have accelerator, brake, gear and steering mechanisms, with separate chassis, body and suspension parts. They can be driven in either front, rear or 4-wheel driving and braking modes, and have numerous other properties and features that can be set or created. They can be constructed to any size or resolution, and their 'chassis' and 'body' HyperMatter objects can be edited into any shape, to yield vehicles with different characteristics, driving styles and performance capabilities. The programmer has at their disposal all the functionality of HyperMatter to customise the vehicle in a virtually unlimited number of ways.


hypermatter care

Because they are physically based, and built from 'genuine' physical components, such HyperMatter vehicles are remarkably realistic, and exhibit many of the same nuances and subtleties of motion as real (or toy) vehicles. For example, when brakes are suddenly applied, or when they suddenly accelerate or turn sharp corners. They can be made to perform all sorts of stunts and to drive over hazardous terrains and obstacles.


Physical Pictures

Physical pictures’ is the term we use to denote moving pictures whose content is computed in real-time, using dynamics, quaternion key-framing and other real-time methods. They can be regarded as an alternative to static images (e.g. jpeg, png) and pre-recorded, animated image or video formats (e.g. mp4, avi).

As such, physical pictures offer several advantages and open many interesting and exciting possibilities. Their primary advantage is the fact that they can run for indefinite duration, without having to repeat or loop, and requiring only a tiny fraction of the memory/data resources of pre-recorded moving images. A physically based scenario would be defined by a few geometry data sets (vertex, face and UV lists), textures, and a script equivalent to just a few lines of text. This makes physical pictures an extremely lightweight and compact means of displaying moving images.

Their other main advantage is that they can be ‘interactive’ (for example, responding to user key or mouse operations), or their scene content 'contextually adaptive', maybe reflecting the (possibly inferred) preferences of their users or recipients.

Physical pictures also offer huge artistic and creative opportunities to authors of e-books, web designers, etc. Imagine, for example, the possibility of moving illustrations in children’s story books, scientific, medical and technical documents, company brochures, greeting cards, and any number of interesting, fun or unusual novelties and gimmicks, etc...etc. The potential user base for such technologies will only increase, as tablets, e-readers, smartphones, and other such devices continue to evolve in terms of their CPU and graphics capabilities. The future is almost inconceivable without physical picture technologies.

The power and effectiveness of physical pictures can only be as good as their underlying dynamics. And, of course, this is where HyperMatter can play a substantial role. The more accurate, stable, robust and fast the dynamics, the greater the range of effects and types of motion that are possible.

Summary of the main advantages of physical pictures:


· Dynamic, real-time, moving images/graphics
· Minimal data/memory resources
· Indefinite (arbitrarily long) duration
· Interactive
· Contextually adaptive

real time page turning

(The HyperMatter Demo Standalone includes a real-time page turning example scene
with a physically based illustration similar to the one above.)