Home » Featured, ICE, XSI

Retiming ICE caches

2 October 2009 27,388 views 13 Comments

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:

  1. 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!)
    • Pros:
      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.
    • Cons:
      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.
  2. 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.
    • Pros:
      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.
    • Cons:
      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.
  3. 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.
    • Pros:
      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.
    • Cons:
      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.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)


  • Rob Chapman said:

    Hi Andy , Great Tutorial & very informative. I was going through this because I wanted to slow down an existing simulation by half which was captured at 25fps without having to resimulate at 50fps

    I think ive got it working by plugging the current frame into the warp fcurve input and adjust the fcurve so that the value say at frame 150 = 75 AND Swapping the ceiling & floor around in the ‘Retime Particle A’ compound. what you recon? am I flawed in thinking this works? it looks ok so far πŸ™‚

    thanks again

  • AndyN (author) said:

    Hi Rob,

    You shouldn’t need to swap the floor and ceiling nodes. By my reckoning, it’ll make the particles interpolate the wrong way round as it goes between the surrounding frames. You know… thinking about it, the fact that you’ve slowed it down by a factor of 2 means that you won’t notice this happening, as you’re only ever seeing it half way through the interpolation (at t=0.5 it doesn’t matter which way round you get there).

    If you try slowing it down by a factor of 10, I’m pretty certain you’ll see the particles interpolating backwards and jumping around as a result. In fact, this is exactly what the Mixer does at the moment, which is the bug I mentioned on page 2. Let me know if this is what happens with your setup.

    Anyway, I’m glad you found the tutorial useful. Thanks for the comment.



  • Rob Chapman said:

    Aha yes you are right. setting a different speed other than 0.5 makes the cache playback all over the place. oh well I’ll just resim at 50fps and keep the compound for speed ramps which im positive will be needed in the future πŸ˜€

    many thanks for your time.


  • Jasper S said:

    Thanks for the tutorial, very well written and explained. Even a complete ICE-noob like me managed to recreate the compound (and learned quite a few things along the way).

    Like Rob above, my aim was to slow down a simulation, no ramping involved. I took out the fcurve node and replaced it with a ‘current frame’ followed by a ‘multiply’ – this seems to work correctly, no jumping around of particles.

    The only thing I’m having problems with is the motion blur fix – the ‘get self.pointposition at previous frame’ node. Is it a ‘get data at previous frame’ node referenced to self.pointposition? I get 0,0,0 value out of that (checked with expose value hack node). I suppose I’m doing something wrong there.

    (As said, I’m new to ICE, so forgive me if this is too easy to answer)


  • AndyN (author) said:

    Hi Jasper,
    Good to hear that you found the tutorial useful.

    Yep, you’re right; the “Get self.pointposition At Previous Frame” is exactly what you said it is. I’ve recently discovered that there are some issues with this node if you’re doing any deletion or cloning of particles, but otherwise it should work okay.

    It’s hard to give advice without seeing your ICE tree and setup. If you want to email me a screen shot, I’ll see if I can help. (I’ll send you my email address in a sec)



  • abacus center said:

    An excellent presentation. Clear. Practical. Insightful. Shows a depth of experience. Thank you. I learned a great deal.

  • sebastian said:

    this simply works like a charm.
    thanks andy

  • AndyN (author) said:

    Thanks Sebastian!

  • Siaamak said:

    Thanks.. Nice

  • danie said:

    Hi Andy

    This post is quite old but I am sure it will still work in xsi 2013 right? I Think I have done everything like you did but when I replace where you had the custom fcurve node with a scalar node and change the value nothing happens, am I being an stupid?

    The thing that might cause this could be the cache on file node. Not 100% what their settings are suppose to be. Does it have to be the same simulation with different frame rates? Currently I have the same ice cache on both but according to me now I am just blending between the same cache, so won’t see anything?

    Any help would be greatly appreciated, and thanks for the insight as well!

  • danie said:

    Hi Andy

    Just an update, did not hide my original cache, so it is working but there is something still bugging me.

    My cache is only starting to show on frame 6, but I cached all the frames (from 1), any idea why this is happening?


  • AndyN (author) said:

    Hi Danie,
    It’s very hard to diagnose just from your description. You might want to check your simulation environment settings to make sure that they’re set correctly to your timeline.

    Alternatively, export your ICE nodes as a compound and bring it into a brand new scene to see if that makes a difference. If it doesn’t, then there’s either an issue with your ICE tree, or maybe there’s something odd in the way that you cached the files in the first place.

    Hope that helps πŸ™‚

  • Danie said:

    Hi Andy

    Many thanks for coming back to me, and yes you are right. Just wanted to double check that it is not something I am doing wrong. Will check out my settings, but works perfectly (even losing a few frames at the start).

    Many thanks for the thorough explanation, loving the functionality!

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.