I used to think refmodels were buggy, annoying and out to get me. After some exploration, they exhibit a couple patterns of fixable issues. Let’s bring them to light, shall we?

Here’s some of my observations with them in the context of artists animating a referenced rig in production:

• StoredExpressions doesn’t always store expressions. They actually show up in StoredPositions almost every time you touch something with an expression. They often also break / stop evaluating when this happens. (They often get stored even when you disable storing of expressions in your Delta, but it’s hard to repro.)
   
• StoredPositions remembers transforms by the mere act of selecting and having translate/rotate/scale tool active. While not exactly a bug, it easily causes problems if you edit centers later on, because the transforms get remembered and so it causes a wacky offset.
  Stuff can exist in both StoredPositions and StoredFCurves but it shouldn’t. If it’s keyed/animated, keys take priority, which means you got redundant junk in StoredPositions. XSI won’t remove the StoredPositions entry when setting a key (which makes a StoredFCurves entry.)
   
• StoredPositions will (from time to time) remember changes to a referenced material’s parameters. This combines with the annoyance of updating a material later and having old values mysteriously enforced on it because they were in StoredPositions and shared the same names. (Maybe a better name is “StoredValues”, since it stores more than positions.)
   
• Generally rigs don’t come preanimated so there’s no point for “StoredRemoveAnimations” to exist. It gets created whenever you remove keys from something in the rig.
   
• StoredConstraints remembers constraint relations by explicit naming. Sometimes these don’t update when the objects name changes, and sometimes they do.
  So say if you constrain an arm of the referenced character rig to a null you just made, THEN rename the null, there’s a very high chance when you save and reopen the constraint won’t be connected, since it will be expecting the original null name. The good news is you can open the Delta in an Explorer, doubleclick the StoredConstraints subproperty and rename the object names in each row to whatever are the correct ones.
   
• Whenever you edit contents of a Delta by hand and want to see the updated result, you must rightclick on the referenced model in an Explorer and “Update Referenced Model.”
   
• You need a Delta per model… and in the case of having a rig with one or more models inside it, this rule still applies.
   
• Just because a Delta sits below a model that doesn’t necessarily mean that is the model it’s working on. It’s actually working on whatever its “Target” parameter specifies.
   
• If “Record” isn’t ON (in the Delta’s PPG) before you make changes, they don’t get saved. End of story. — Turning it on after doing changes won’t save your ass. (Good thing it’s on by default, eh?)
   
• If you have a convoluted/complex rig that crashes when you do “Update Reference Model” or when simply offloading, but works fine otherwise… if you need to update the refmodel path, you can do this without opening your scene by editing the relevant scntoc file and then when you open your scene it’ll be path you wanted. 🙂
   
• When you duplicate a material from a referenced model, it duplicates fine EXCEPT for the image clips/sources, which stay referenced and when you reopen the scene, they will have dissapeared.
   
• Using Animation Layers with referenced models is not to be trusted. [*update*: Steven Caron from Blur Studios has noted that as of Soft 2010 SP1, animation layers work fine with referenced models. Beware if you are using a previous version.]
  If you use them, always open the scene you just saved in a new XSI without closing the first one so you can check that when it opens all the animation is still there and works properly. (I haven’t confirmed, but I believe I read on the mailing list that you can collapse animation layers before you save and then it’s okay.)
   
• Someone on the Softimage mailing list mentioned once that only the first Delta for a particular model remembers Mixer stuff like actionclips and such, regardless of what you set. Good to bare in mind.
   
• [*Update 23/Dec/2010*] Eric Thivierge has brought up that apparently if you key a refmodel’s object to another and animate the Active parameter, those keys will not be saved. However, if you key the Blend instead, you’ll be fine.
• [*Update 05/May/2011*] There’s a very interesting SDK bug (confirmed in 2011 SAP, not checked other versions) whereby dealing with Model Instances with refmodels will create an instance group and seems to work fine, but if you try to get the .ActionDeltas of the Delta via scripting, it will fail as if it didn’t exist. Rename the group once and then .ActionDeltas work again. Very strange!!
• [*Update 13/May/2011*] With 2011.0 (the first one) there is a serious bug whereby shaders may get disconnected. The bug that causes the issue is fixed in the ServicePacks that followed. Inform yourself straight from the source at Stephen Blair’s eX-SI Support blog.

At work I made two relatively simple scripts that help us with refmodel woes. I’d like to share them with you:

“Import Referenced Rig”:
If you do File->Import->Referenced Model and begin working without doing anything, it’s set to remember *anything* and *everything*. It’ll break in no time.

This really simple script imports a refmodel, make a fresh empty delta for it (and extra Deltas for any models in it) and sets these defaults automatically:

• Static Pos and Other Parameters ON
• FCurves ON
• Expressions OFF
• Constraints ON
• Animation Mixer ON
• Group Relations ON
  (this stores partitions relationships so it’s very important!)
• Model Instances OFF
  (could be left ON if you need it)
• External Connections ON
  (this remembers stuff like constraining something in the refmodel to an external object)
• New Properties OFF
• Clusters OFF
• Cluster Properties OFF
• Operators OFF

then in Mixer Modifications:

• Animation ON
• Shapes OFF
• Audio ON
• Cache ON

These are the ideal settings for using a referenced model to move/animate it, put it in partitions/groups/layers and render.

Download the AF_ImportRefModelForAnimation.py Python script here. Make it into a button or incorporate it into your workflow tools if you have any.

“Clean Delta”:
It deletes stuff from a Delta that shouldn’t be there if you just wanted to animate and render a referenced rig or model. See the code for more specifics.

Download the AF_DeltaCleaner.py Python script here and run it from a button with refmodels selected. I’ve left plenty of code comments to make sense of what it does. I urge you to read them.

I hope these scripts assist you in having a more pleasant experience with referenced models. They’re actually quite wonderful after you learn their quirks.

If anyone has anything else to say about deltas, modifications, suggestions, code improvements, constructive critique, cheese and monkeys, etc. please leave a comment. Thank you. 😀