Retiming ICE caches
Occasionally a project comes along that has different frame rates in the edit. Sometimes it’s worse than that, certain shots can have the frame rate changing continuously; a technique that’s often called “speed ramping”. For example, imagine the real time to bullet time transition in The Matrix.
For the Sky Sports “Super Sunday” ident we worked on this year (Mill article), almost every shot had some amount of speed ramping. Needless to say, this is usually where the FX TD has a minor heart attack in anticipation of the hell that he or she is about to go through. However, the flexibility of ICE in XSI now makes the process relatively easy, and this three page article will show you how to do it.
Why is speed ramping a problem?
Physics engines in 3D applications tend to do their calculations on a per frame basis and they assume that the length of time that passes in each frame (known as the simulation step in ICE) isn’t changing. It’s an important optimisation as it simplifies the problem for them.
Numerical accuracy for collisions, and forces such as damping, are highly dependent on the simulation step. If the simulation step was allowed to change on each frame, it would introduce erratic behaviour into your object or particle motion.
Another problem you’d notice is that for different speed ramps, you would get different results from the simulation. Small inaccuracies in the way the simulation is calculated give rise to larger effects later on, despite starting with the exact same initial conditions. The key point to note is that larger simulation steps are more inaccurate than smaller ones, and changing the speed ramp means that you’d be introducing those inaccuracies in different places. This isn’t much good as you might have to redo your simulation if your speed ramp ever changes (which on our Sky job, it did on a number of occasions).
Methods for dealing with speed ramping
There are three ways to deal with speed ramping at the 3D stage:
- You add support for speed ramping into your physics engine. Actually, for particle simulations this isn’t as hard as it sounds. You just have to create your own “Simulate Particles” node. For rigid bodies… well… good luck! There’s a lot of maths involved, and it’s far from easy. Plus you’ll have to write your own collision system. (Yeah… no thanks!)
If you can get it to work, it’s a simple way of achieving the right result. You just run your simulation and you get the result.
For anything other than particle simulations in ICE, it’s not particularly viable unless you’re good at physics programming. It would introduce inaccuracies. If your speed ramp needs to change later, you’ll have to re-simulate, and there’s no guarantee you’ll get the same results.
- You simulate and cache the simulation at the same frame rate as you’re delivering the final sequence (in our case, 25 fps). At render time, if you need to go to slow motion, you’ll have to stretch out the simulation to slow it down. This means you’ll be trying to render at non-integer frame numbers and you’ll have to interpolate the particle positions and other attributes.
It’ll be fast and you won’t have much data to cache. You’re doing the minimum amount of work needed to get the result. If the speed ramp has to change, you don’t need to re-simulate since you’ve cached out all your data.
It’s unlikely that this will look very nice if you have any collisions, as any sharp changes in velocity will look sluggish due to the interpolation. You might get away with it though, so it’s worth a try if you are up against a tight deadline.
- You simulate and cache the simulation at the highest frame rate that you think you’ll need (in our case that was 100 fps). At render time, you’ll usually be replaying the cached simulation faster (e.g. when it’s running at 25 fps) by missing out the frames you don’t need. To guarantee smooth animation, you still need to interpolate between frames, as more often than not the dynamically changing frame rate will result in non-integer frame numbers.
Calculating at the highest frame rate means that your simulation will be super accurate. As with (2) if the speed ramp has to change, you don’t need to re-simulate since you’ve cached out all your data.
You’ll be spending a lot of time simulating and have a lot of data to cache.
What we used on Sky
The third option is nearly always the best way to go. It’s a good solution, providing you’ve got plenty of disc space, and have enough time to do the simulations.
For Sky, we animated and simulated everything at 100 fps and cached all that data to disk. (If an analogy helps, just think of it as filming live action with a high speed camera).
For each shot, we had a curve that represented the current frame to load from the disk cache. This curve was an incredibly important asset in our pipeline as it was used to synchronise multiple packages (XSI, Houdini, Maya, Massive, Cinema 4D) to render everything at precisely the same moment in time.
Note that since the speed ramps gave smooth changes in frame rate, the frame numbers given by the retime curve weren’t usually integral values (e.g. 1, 2, 3, 4, etc.), but were fractional (1.4, 2.8, 4.2, 5.6, etc.). This meant that camera and object transforms, meshes, and particle attributes had to be interpolated to be properly evaluated at these fractional frame values. More on that later.
There’s one last issue you need to take into account when doing any sort of retiming of a cache. You can read about that on the next page.