Nokia Friends, generative characters
| Am currently preparing myself for my biggest trip of the year to speak at Semipermanent 2008 in Auckland, next Friday evening. This also means I'll have to finish documenting some more projects and their creation process before and so here's one of them… | Earlier this year Matt Pyke invited me to help creating a motion graphics piece for Nokia's five superlarge 14.8 x 3.36 meters LED screens at the new Heathrow Terminal 5. The concept was simple enough: |
“A procession of diverse characters glide by on a travelator - friends, families, kids, lovers, rugby teams, fat couples, thin models - celebrating the diversity of people seen at Heathrow T5. Every character riding the travelator is unique, using generative software to create an ever-growing population.”
What makes a character?
| So a “character generator” of sorts was needed on this occasion. Again. In 2007 we have both collaborated on another such generator to create 20,000+ unique furry and cuddly monsters as identity for the Lovebytes International Digital Arts Festival, suitably “Process” themed that year. This time though, the bar was a bit higher (not because it was for a global brand, that too!), but the characters really needed to come to live, be animated. | Getting their look and shapes right was just the beginning, though. The main challenge was about coming up with a system for creating behaviours which is a) not only suitable to support the formation & appearance of characters, but b) can also be “shaped” and controlled fairly easily to create a variety of behaviours. Taking Matt's initial static example character designs, it was only a couple of short steps to think of some bouncy behaviours and from there to attempting a physics based approach to modelling the characters as well as letting it drive the whole animation. |
Initial character look & feel by Matt Pyke
A look inside the characters, showing the debug view of the raw physics structures
| To answer the above question and as mentioned in the making-of video, in our case it takes around 60 points and 140-160 elastic springs connecting them in a clever way to make one of these characters in a generative manner. Of course, the springs here are just physical simulations of a real spring behaviour, but even so I decided to write my own physics library because the available ones were either not stable enough (using the standard Runge-Kutta method) or to cumbersome to use and not easily controlled. The good news is, that my lightweight library is using the more stable Verlet integration (also used for Ragdoll physics of various video games) and is now part of my opensource toxiclibs collection too. | Still, a single character alone does not actually do very much, even in the final version. No, these blobbies, how we started calling them lovingly, are truly social beings. It is their interplay and bounciness which is creating the stories as they travel along the screen. To better reflect the airport context the piece was commissioned for by Nokia, we also had to think about creating groups & families of these characters. In the end this was achieved by mutating the design parameters of the most recently created blobbie and use these as “DNA” for the next one. The intensity of the mutation would then cause either a next-of-kin type resemblance or, if desired, a far relative. Compared to other projects, the number and scope of parameters is fairly limited but still powerful enough: |
"We are family!"
Body colour
| Body colours are defined in HSB space to easily create random variations of similar colours (for relatives), whilst ensuring only quite saturated and bright colours are picked. | This is basically done by only picking points (colours) near the outer radius in the upper half of the cylindrical HSB space… |
The different topologies of RGB and HSB colour spaces
Hair styles
| There're 3 basic hair styles a character can have: curly, straight or single curl/hair bundle. | Each style has further parameters like density, direction, alignment and hair length, all of which are randomized for each character. |
Hair style variations
Body shape vs. Body Mass Index
| Nintendo's Wii Fit came recently under a dubious media attack for suggesting "You're fat" to a little 9 year old girl. Well, I also made use of a BMI like value to ensure our characters are not overly obese or too small or too tall. Just a bit like in the real world and because of the physics involved, these individuals would had serious problems, either starting to roll like a beach ball or simply fall over non-stop… | Each body's shape is constructed of a number of interpolated B-spline patches, with some of characters using a couple more than others to create additional little details/protrusions. This template shape is only generated for one side and then mirrored along another semi-random B-Spline acting as the central spine for each character's body. This vertically changing, slight off-centre mirror effect is adding extra quirkiness to the blobbies and also helps them to be a bit less uniform. |
The dotted red lines are the deformed mirror spine/axis for each body.
Attitude & Eye behaviour
| I'm continuously amazed (and amused!) about how the most trivial abstractions or decisions often end up being the most effective too. Take for example the eyes, whose movements and blinking is not just simply random, but based on each blob's “mentality” and nearby environment: | Every character has an attitude value assigned which is used to decide how to behave in “conflict situations”, ie. any collisions with other blobs. If two blobs come too close to each other, the software will create temporary springs between them, in order to push both slightly away again from each other and so avoid blobs getting mangled up. |
Soft body collision detection & resolution using springs (here shown in blue)
| Normally, in a physics simulation both ends of a spring are moved in space to return the spring to its desired restlength. However, each blob's attitude value decides if this default behaviour remains, or if our attitude is much higher, only our “opponent” will have to give way and our body stubbornly remains anchored in space. This quickly becomes very comical if some of the smallest characters end up having the biggest attitude of all and create an insurmountable road block on the travelator. | The blinking and movement frequency of the eyes is also directly linked to that attitude setting and results in staring contest like behaviour for “high attitude individuals” (modelled on standard behaviours observed on the street… ;). In case of collisions with other blobs, I also decided on the following: whoever bumps into someone else will be looking away from his/her victim, whilst the victim will immediately look at the offender and let his gaze follow him for the next 2-5 seconds. |
"Are you looking at me?"
Creating the animation
| Since the software can generate the animation in realtime, but so far did not deal with actual traffic/flow control on the travelator, I decided to not try solving this part in code, but implement the generator almost in the way an instrument works. That way we could literally perform with the software to create different crowd constellations and too have full realtime control where and when new characters entered the travelator. | For that reason controls were kept super simple and realized as “point & click” like interface using different keys to spawn new individuals or siblings. In case a blob is falling over, it can be forced to lift off and disappear again without causing too much trouble. Every session/take was recorded as separate video file. Then it was easy to pick our favourites at the end. |
Discussion