Home » Featured, ICE

Forcing ICE attributes to cache

11 July 2009 12,419 views 4 Comments

If you’re doing large simulations in ICE, at some point you’re going to want to cache your data out. If you’ve tried this, I’m sure you’ve noticed that ICE has a nasty habit of ignoring any custom attributes that you’ve made, and sometimes the regular ones too. A reliable source tells me that this is probably due to the highly optimised nature of ICE, which is one of the reasons that it runs so fast.

Optimisations… meh.

Okay, so we need a workaround and luckily one exists. The idea is to force it to not obliterate optimise out the attribute by telling ICE that we’re using it. To do that, we’re going to use a Get Data node plugged into a Set Data node, with both referring to the same attribute name. In this case, I’m using an attribute called “MyData”.


That, unfortunately isn’t enough. We also need to right click on the “Value” link between the two nodes and use the “Show Values” menu option. Obviously we don’t want to see the debug data in the viewports, so in the Show Values PPG that appears, select “Show Values for Tagged Components Only” as shown below:


Wrapping this into a compound means we can reuse it any time we need to make sure that ICE exports a particular attribute.



Finally, don’t forget to check the box for your attribute when you come to caching the data out using Animation->Plot->Write Geometry Cache.


Our attributes should now be cached properly.

Problems loading the attribute?

Occasionally you might find that the attribute doesn’t seem to be present when loading the cache back in. So how do we force ICE to load the attribute?

A method I’ve found that seems to work involves “reserving a space” for the attribute by creating one with the same name, and the same context. But we only want to create the attribute if a valid one doesn’t already exist, so that we don’t trample all over the data.

So for a scalar attribute with a per point context, we can do something like this:


The Get Point ID node is just used to initialise the correct context of the attribute as per point. We really don’t care about the value it provides. Specifically, the Get Point ID node is being used because it seems to be the most reliable in providing a valid value (it rarely goes red, even when the cache is missing). We convert it a scalar since that is the type of attribute we’re trying to load. If, for example, we were loading a vector attribute, you would just pipe this into a Scalars to Vector node before the Set Data instead.

Again, we can wrap that into a compound for ease of reuse. Bear in mind that you’ll need to do this for each different type of attribute and context.

So to clarify (and referring to the image below): In the ICE tree whose data you are caching, use the first compound (it doesn’t matter where you put it in the tree). If you have any problems loading the attributes, use the second compound plugged into the first port of the ICE tree node.


That should ensure all your custom attributes are cached and reloaded correctly.

Please note; as with all these types of ‘hack”, there will almost certainly be a situation where it might not work. If this happens to you, please leave a comment below or contact me here. I can then make sure that the most up to date information is on this page along with any other hints or workarounds. Thanks.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


  • Guillaume Laforge said:

    Great to see an ICE article on your blog !

    I agree that the ICE optimisation design can be a problem sometime and your solution is often needed to get a correct evaluation of custom attributes when they are not used to change values on factory attributes.

    The show value option is the fastest/simpliest way to get the correct evaluation, but to avoid a slow display on large cloud, you can also add an attribute display property to your ICE cloud. It should force the custom attribute too, even if not displayed in the viewport.
    I also use some math operations to force the update like this : "PointPosition + (my_attribute – my_attribute)" or "PointPosition + my_attribute * 0". It should add more processing but the contribution to the total evaluation duration seems very low to me. The advantage is that it can be use in batch mode. I’m not sure if the "visibility hack" works in xsibatch.

    I will try your tips to force the attribute loading. It seems very clever !

  • AndyN (author) said:

    Thanks Guillaume. Yep, more ICE articles to follow!

    >>but to avoid a slow display on large cloud
    That’s why I turned on the “Show Values for Tagged Components Only” option. It doesn’t show anything if you don’t select the particles, so in theory there’s no slow down. I haven’t tried this on any huge point clouds though.

    That’s a great suggestion about using PointPosition. I tried modifying the attribute with a different approach, but didn’t think about involving something like PointPosition while doing it, which would explain why it didn’t work!

    James Rogers also pointed out the issue with using this method in batch mode, but I forgot to include it in the post. Thanks for mentioning it.

  • Rob Chapman said:

    It works! ive not had many problems with this before, based on luck I presume, plus I always seem to duplicate my original pointcloud for the cached version and a heavy handed approach by forcing the attribute name as an empty value in a seperate model Ice tree, then it suddenly seems to work, or alternatively, most of the custom attributes ive used can be recreated from the cache itself.

    anyways was stuck with a custom attribute that refused to come over from the cache and this technique worked a treat, many thanks Andy!

  • AndyN (author) said:

    Good stuff. Glad it worked!

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.