Let’s do it in Real-Time!
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
- 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
Cheers,
Curtis Garton
In order to post any comments, you must be logged in!
Posted by Elboncutlass on 02/26 at 04:37 AMHello Curtis,
Your post is very interesting.
I do agree with Kees: a tool that could detail the “time budget” that is used by the elements of a given scene graph would be extremely helpful. It would allow the user to make much better decisions on the compromises to make in order to optimise a scene for playback.
Thinking broadly, with such a “time budget evaluation mechanism” a Maya user could use MEL to build a conditional refresh engine that drops features instead of entire frames when certain time conditions are met, such as: “if object X deformation takes more than 15 ms, then turn bouncing box on”.
That would change your definition of real time from a system that drops frames, to a system that drops features, the important difference being that now your 3D could more easily be synced to video, for instance.
What do you think? - David
Posted by kees on 02/22 at 10:15 AMAs an example.
I may setup a complex rig in 3dsmax of Maya that turns out to update at a lower framerate then is deemed pleasant by the animators.
It now because a painful task to try and identify which elements are causing the poor performance so you can try and find an alternative setup that may work better.
So some tools that could identify which elements are sucking up a lot of resources would be very useful.
I.e. viewport rotation slowness may be caused by to many vertices, or perhaps the textures are to huge, or maybe there is a single poorly programmed modifier plugin that is causing it.
It takes so much time to identify what is actually to blame for the slow downs.
Usually fixing the issue isn’t so hard as identifying it.
Hope that makes sense,
-Kees
Posted by kees on 02/22 at 10:06 AM"MotionBuilder [...], its ability to deliver real-time playback of content is completely dependant on your hardware; video card, cpu and ram.”
Wouldn’t it also depend on the quality of your programming? 
Anyway, nice post. To me ‘real-time’ for something like Max or Maya simply means an interactive rate of update that is acceptable to an artist/animator so they don’t have to wait while performing their next ‘artistic’ action.
I.e. when moving vertices, 10 FPS may be fine, while animation playback may have to happen at 24 or 30 FPS for the artist to get proper feedback.
I think a lot of people see ‘real-time’ as 30 FPS or 60 FPS or whatever number.
Which, is only a value significant for games.
I think where Max and Maya (etc) can improve is to allow the artist/animator to customize more what is important for them to be fast and what is important for them to be accurate.
To some degree, this is already possible, but I think it is hard to identify sometimes what are the costly elements in a scene when pressing the play button and you are not getting that 24 FPS.
What do you cache, what do you hide, what do you reduce in size / memory… etc.
-Kees
Page 1 of 1 pages
