Forcing ICE attributes to cache
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.
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.