Home » 3D, Featured, ICE, XSI

Nested ICE compound hell

4 July 2010 10,606 views 3 Comments

It seems to be a general rule that just when you think you know a bit of software, it comes back to bite you on the ass. This time, ICE threw up a surprise when I went to import a compound. It seemed to come in okay, but it complained in the script window. It couldn’t find a compound that was used inside the one I’d just imported.

I had assumed that XSI embeds the definition of compounds used within exported compounds. By default, this isn’t the case, and I had forgotten that I had renamed the internal compound to something else.

So it turns out that there’s an innocent little option on the Export Compounds dialog called “Embed internal compounds”. It’s off by default, and I’d strongly recommend turning it on every time you export your compounds.


If you don’t tick that little box, XSI only stores the names of the nested compounds. That means that if any of the internal compounds get moved, renamed, or deleted, your main compound will no longer work.

What’s potentially worse, is that if you update one of the nested compounds with a slightly different functionality, then the behaviour of your main compound will change too. This is particularly bad because this would happen invisibly to you. No warning, no error messages, no nothing.

Aha, you say, but what if there’s a bug in that nested compound? Isn’t it desirable that fixing it will propagate to any other compounds that use it? Yep, sure that’s handy. However, if you’re working in a pipeline and store your compounds in an SVN, your compound has just changed behaviour and it has no associated version checked in to allow you to roll back if needed. It makes it impossible to track versions.

In short, if you don’t tick this innocuous little box, you’ll end up creating compounds with a spiders web of dependencies on each other. You could end up with a situation reminiscent of Windows DLL hell.

Believe it or not, it’s actually possible to create infinite recursion with circular references. If you make one, it’ll export okay, but when you drag it back in, XSI will hang as it tries to add nodes inside of themselves. Admittedly, this is a bit of a contrived situation, but it should serve as a warning that not embedding your compounds is a bad bad idea.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


  • sko said:

    Did you try to increment the major version number of your modified nested compounds in case of bigger changes? I’m under the impression this would keep it from rippling up.

  • AndyN (author) said:

    That’s a good point, I haven’t tried that.

    Either way, I’m still gonna stay away from referencing. For me, the benefits it offers don’t make it attractive enough to ignore the potential nightmare. Especially in a production environment. You never know who’s going to change or reference something, and it’s impossible for anyone to anticipate the consequences of those changes.

  • Guillaume Laforge said:

    I agree, referencing can be a nightmare ;).

    But there is a little trick to simplify your compounds versioning.

    If you increment a “sub-compound” to a major version (for example 2.0) the main compound will use the version from when it was saved (“sub-compound.1.0” for example. So it will always work if you keep the 1.0 version on disk.

    Sometime it can be really handy to use referenced compounds. That’s why I mentioned this trick, just in case someone was no aware of it ;).

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.