Horse Tail: Physics simulation in My Horse and MeMay 21, 2011 Physics
The game My Horse & Me by W!Games is all about riding horses. For this game, I implemented the horse’s tail physics in 2007. The tail was prototyped first as a separate application, and later ported into the actual game. If you’re interested in how it worked, read on. Or, if you prefer, directly scroll down and see or try the prototype in action.
The images above are screenshots from the prototype. There are two different approaches visible in the leftmost image: A strand simulation on the left, consisting of 400 chains of simulated (orientationless) vertices, and a bone-and-skin simulation on the middle and right, respectively. These two different approaches are explained below, starting with the many-strands approach.
The simulation and rendering of 400 individual strands, each with a slightly different length and stiffness, results in a voluminous set of curves, reacting smoothly to every movement, rotation and collision. It also requires quite a lot computing power, however, making it less appealing for a console (e.g. Wii) game. Yet it does serve as a good reference implementation to aim for while using a less expensive and more traditional skin/bone approach.
Each strand consists of 11 line segments connecting 12 vertices into a chain. Each strand are simulated independently from each other strand, avoiding the problem self-collision. Each vertex is a simulated point mass with its own 3D position and velocity, but without any orientation. Each frame, all strand vertex positions are updated using Verlet integration and are kept at a fixed distance from each other and from other blocking (body) primitives using projection, similar to the iterative techniques discussed in this Gamasutra article.
Bending stiffness is simulated using a ‘softer’ vertex projection, pushing each vertex closer to the line passing through its two neighboring vertices, resulting in less chain-like and more rope-like movement. Yet, the strand segments have no torsional rotation and stiffness, as they are only defined by pairs of orientationless mass points. This, however, isn’t objectionable as strands are (infinitely) thin objects anyway, and only combined define the tail’s volume.
In the prototype, the segments in each strand are rendered as quads, using the two old and two new point mass positions of each segment as quad vertices. That way, a nice one-frame motion blur effect is added to the tail with little effort, as can be seen from the first movie clip below.
Skin and bones
Although the many-strand approach did result in the desired movement for the horse’s tail, it also required a lot of processing power. Too much, anyway, to be of any practical value for My Horse & Me. What I needed was a faster approach, that would still result in similar movement and volumetric appearance as the many-strands simulation.
The approach taken was to find a way to simulate only a single strand to somehow drive a chain of bones that controls a skinned tail model. Naturally, each individual strand segment could be used to drive one associated bone. Yet, strand segments only define a position and direction, but not the full 3D orientation that is needed for a bone.
To fix the orientation problem, the problem is reversed for the first frame on the simulation, using the bone positions from the original model to derive the strand mass points positions from. For each subsequent frame, a shortest arc rotation is applied to each bone orientation to align its Z axis to the latest direction of its associated strand segment. In other words, the bone chain is made to match the strand curve using each bone’s two non-torsional orientation angles.
The torsional orientation angle of each bone (i.e. the rotation about a bone’s local Z axis) is updated differently. Each relative torsional angle between adjacent bones is minimized over time towards a torsion-free parent -- child orientation, like a torsion spring between adjacent bones. That way, any local difference in twist will smoothly be propagated both up and down the tail until the whole tail is twisted uniformly.
By now, the movement of the skin-and-bones tail matched the many-strands solution pretty closely. Yet, the volume of the many-strands approach is still more dynamic. For example, the strands subtly fan out when the top of the tail is twisted, like swings in a merry go round.
To simulate this (without the help of non-uniform scaling), the bottom half of the bones was changed to consist of three bone subchains that act as swings around the single bone chain.
The distance between each bone in a subchain to its associated center bone in the single bone chain depends on the center bone’s torsional velocity. By scaling up this effect towards the tail’s tip, the tail’s volume at the tip will increase more than at the top when being twisted rapidly, mimicking the effect obvserved in the multi-strand approach. See the beginning of the prototype movie clip below to see it in action.
The clip below also demonstrates the resemblence between the two approaches in terms of movement, the collision response between tail and collision primitives (the ‘horse head’) using projection, and the tail’s natural motion when attached to a (violently) moving source (again, the horse’s head…).
The in-game footage below shows the final result, once the skin-and-bone code had found its way into W!Games’ My Horse & Me for the Wii and PC.
- Download the prototype application (32-bit Windows binaries)
January 3, 2012
February 5, 2012
Like the blog
July 1, 2012
Hey, I’m really enjoying the articles on your site. I especially enjoyed the network latency for celphone games article… Do you know the more recent cell networks like 3 and 4g have similar latency? I am working on an android game, and I am considering attempting multiplayer… Also, the Armed Mine article was really cool! Great rundown of the doom physics implementation, and the videos were awesome! Playing with the horse tail simulator now… Great blog! Thanks!
July 1, 2012
Hi Mister Stick! That’s great to hear! I haven’t performed any actual tests with those platforms, but from what i gather 3G with decent reception is typically near or in the range of 200-300ms roundtrip. But when the signal strength is (quite) poor, this number can increase considerably. Presumably because it might require multiple attempts before the packets are actually received correctly and passed on. Also, all GPRS communication for Razor was done using HTTP connections if I remember correctly, as using sockets/TCP/UDP directly wasn’t very well supported on those devices. This added to the roundtrip overhead (as well as bandwidth usage), as messages will only be passed on to the application when all bytes have been received. I would assume this situation has improved since then through better hardware, drivers and APIs. (Though HTTP may still be the preferred protocol for any specific application for other reasons, of course). Good luck with your game!
December 13, 2011