This book is a work in progress, comments are welcome to: johno(at)johno(dot)se

Immediate Mode Animation Systems

RM vs IM animation systems (Ground Control 2 / Skeletor):

RM problems:

• caching transforms (Instance) when they change every frame
• access to animation data was hard/impossible, i.e. syncing sounds and particles to animation -> renderer/animation system controlled everything
• control over specific bones was problematic

IM / Skeletor pros:

• less code
• no guesswork on the part of the library as to what the application wants to do
• setFrame(anim, time) interface, also blending
• ease of event syncing to anims (get frame back from setFrame())

In general, why did such a rigid interface evolve between app and renderer at Massive? Why did every attempt at a renderer result in a RM interface? Why do people insist on building RM on top of IM (DirectX)? Why scene graphs (Tom Forsyth?)

core::Versioned/implicit cache management: Talk about the reasoning behind this relating to reducing the number of explicit caches in the system.

Talk about immediate mode animation, in that you can often get away without any per instance data (i.e. current state or frame), or in cases like Azaya with very little (i.e. a single float per instance which stores the current local time, for effects like tying animation to the world-space speed of an avatar).