With all the talk about real-time cinematography , real-time runtime components and of course, real-time motion editing, I thought it was time to shed some light on what does ‘real-time’ actually mean.

The term “real-time” has been used in many different contexts and has taken on an almost mythical definition of “something really fast, like a video game….but looks better”. I have yet to meet such a creature, but I am still hopeful to cross paths with one someday.

The first attribute or quality of a real-time application/engine is that it is time-playback accurate. What this means is that a 30 second animation will playback in 30 seconds, regardless of the frame rate being achieved. More precisely, the system will drop frames when necessary (ex: complex geometry/deformations) to ensure that playback is time accurate. This can be critical for doing performance animation with audio, video reference or other time sensitive animations.

The second quality of a real-time system is the manner in which it is architected. Video game engines are specifically built for delivering high frame rates, ensuring a smooth experience for the user. This is at the sacrifice of flexibility and “editability”. The notion of being able to edit content, whether it is animation, geometry, mapping, etc. requires considerable flexibility and openness of a system’s architecture, which can reduce performance and the ability to achieve the necessary performance playback speed for gaming experiences. Content for video games systems is also optimized and compressed for optimum playback, again removing flexibility and the ability to easily edit content.

The third element that can be attributed to a real-time system is its ability to run a constant evaluation engine. Typical 3D applications perform scene evaluation only while playback is occurring, and then stop once the duration of the timeline is exhausted. Real-time systems are constantly evaluating (watch your Task Manager Performance meter while MotionBuilder is running as an example of this), allowing for a whole variety of applications and workflows. Need a few examples?

- Capture the movement of your mouse as input data to drive a 3D characters eye movements
- Feed live input from a motion capture system to visualize animation data on 3D characters while they are being performed by live performers (read: live cinematography)
- Trigger animations and events based on predefined rules (video games anyone?)
- Visualize particles, lighting and FX without performing a render

Now, the notion of real-time is not without its limits and more than not, people tend to get caught on how any system could be so fast, even with their 3million poly character that has 2GB of textures. Real-time systems are typically best-effort systems, meaning they evaluate as fast as they can with the data that is loaded, on the hardware in which the system is running. In the case of MotionBuilder (to which I get many, many questions about performance and real-time capabilities), its ability to deliver real-time playback of content is completely dependant on your hardware; video card, cpu and ram.

Real-time engines are not without their limits, and I know of no system that provides the flexibility of a 3ds max or Maya, with the performance of a video game engine. The key here is tuning, both on the systems side (ex: MotionBuilder being built for real-time playback) and on the content side (being smart about how you create and optimize your models, textures, etc.). With the correct balance, real-time systems provide the performance artists require to focus on the task of animating vs. waiting for the software to “catch up”.

Cheers,

Curtis Garton