As with  syncing props to animated objects, syncing 2 (or more) animated objects presents a similar challenge. But in the previous post, the problem was a little easier. Basically a character moves to a registration point and an event is triggered. The event calls synced animations on multiple objects and the objects interact. Pretty simple.

However, syncing becomes difficult when two complex animated objects with layers of blends & animations need to interact in unison. To avoid making a programmer write spaghetti code & painting oneself into an art production corner, it's better to abstract the interaction with the use of states. In Unity, a state tree can drive a network of animations; simple to complex. Two (or more) objects can share the same state tree and unique animations can be called per object via overrides. So two dissimilar objects can interact together as they transition from state to state. Very slick. Below are some simple examples of how states keep animated objects glued together.

Side Note: To abstract art production a little further, an "object" can be only a hierarchy for transforms. Meshes properties can be attached as needed. Below you can see how the bike is a bunch of mesh parts attached to a 'naked' hierarchy of bones, making it's components & paint upgrade-able.

Setting-up & registering multiple static & dynamic objects to create a "cookie cutter" standard in which all Unity prefabs will derive from. In this example: The character's "sit-in" and "sit-out" animations sync with the dynamic chair's "sit-in" and "sit-out" animations. Both the character & chair are spatially registered to the static table. So long as new mesh objects are created to match this standard, this system can drive different table & chair combos.

The same method works for registering & synchronizing deformable props with animated  objects as well. So long as the bath tubs & shower curtains in the game conform to a standard, the objects will interact perfectly when triggered together.

Got some very good performance results running many of these characters on a Nexus 7 tablet. The exported FBX file has 60 bones and 5k triangles. Mobile isn't for low resolution graphics anymore! The videos below show the animated rig in Softimage and the exported result running realtime in Unity.

I continued testing flexible, stretchy, & stylized rigs & animations in Unity. I made this mockup character... let's call him "Boxy". In the first video, you can see Boxy's rig driving the STR values of nulls (the yellow dots). In the second video, the plotted nulls are driving the same deformations in realtime. Pretty slick!

You don't see many exaggerated squash & stretch style animations in 3d games. When I worked on Half-Life 2 I rigged & animated the Barnacle character who had lots of realtime squash & stretch deformation. Like many engines, Source threw out the scale data, so I had to use only bone translations & rotations to make him bendable. Now days modern game engines support scaling and Unity supports scaling bones! So testing basic bone scaling. Below you can see my results from the 3d app and plotted to realtime bones in Unity.

As a generalist, I keep all the 3d skills sharp. When I haven't touched animation in awhile, I go back to fundamental exercises. It's all about the basics.

Wired up a Half-Lambertian shader. It's a nice technique for simulation slight subsurface light scattering or very rough objects where light energy would be transmitted from it's hit location to nearby matter. Nice soft fall-off made famous in this Valve paper.

I've uploaded a preset for this material. Note that this material uses a vector share node (I've commented it) to calculate shading; not a light.

Sit, Ubu, sit! Good dog.

Go fetch.

Many game engines are using deferred rendering these days as opposed to forward rendering. In addition, many movie shots have been authored with deferred techniques and then assembled and shaded in Nuke. The concept for both real-time engines and offline renderers is basically the same; to encode 3d data into 2d space (buffers) and then solve for the lighting/shading as a post process. If you are interested in lighting/shading in post, check out the Postlight tool by Andy Nicholas.

This deferred texture mapping test is a similar idea and mimics thistool by RevisionFX. For offline rendering, this additional UV vector pass can save re-rendering an image/animation by allowing me to swap textures after rendering is complete.

The Component Parser is the compositing node used to map the texture to the UV vector data. The variable a1 = horizontal pixel count of the image and variable a2 = the vertical pixel count.

Objects can be easily textured in post. Swapping textures is real-time without the need to re-render.

This is a great cheat for low cost 'dynamic' lights. If you bake lightmaps in passes, this is a very easy effect to author.

Essentially I combine two lightmaps; adding the dynamic map over the base map. For this demo, I do exactly that. In practical application, you would not want to double your lightmap textures space for a whole level. Instead, create a pass where duplicate chunks of localized geometry will hold low resolution dynamic maps (or even make a larger texture sheet for all the dynamic maps in your level, a 512x512 will do) and bake to a new set of UVs.