Okay so here’s how it works:

1. Create your geometry and rig
2. Put rig and geometry into two different models
3. Create the connection (envelope, constraints etc)
4. Export FIRST the geometry, and SECOND the rig.
5. Go to a new scene and import FIRST the rig and SECOND the geometry as referenced models.
6. To ensure the models are loaded in the right order in the future, also name them alphabetically in that order. (in my example I am using numbers to set that order)
7. Put both ref models into a new one and export it as the “fullmodel”.

You end up with three files. The first one includes just the geometry + envelope operator and weightmaps, the second one includes just the rig, and the third one, the “fullmodel”, includes just two file pointers to the previous two.

If you want to go ahead and make changes to the rig, you can externally, while just loading the rig up and modify it. If you are about to change the geometry, and you don’t want to loose the envelope, just open up the fullmodel, localize the submodels and do your edits, afterwards convert the geometry back to referenced, and reload the “fullmodel”.

Below you can see a working example in the explorer, and a repro script to generate this setup. All steps (also changes on the geometry after the connection has been established) are part of that script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

var project = ActiveProject.path;
NewScene(false,false);
 
// create objects
CreatePrim("Cylinder", "MeshSurface");
Create2DSkeleton(0, 3, 0, 0, 0, 0.5);
AppendBone("eff", 0, -3, 0);
 
// create models
CreateModel("root", "_0rig");
CreateModel("cylinder", "_1geo");
 
// reset the transform of the models so
// they are in the center of the world
SetUserPref("SI3D_NODETRANSFORM_CHILD_COMPENSATE", 1);
ResetTransform("_0rig", siObj, siSRT, siXYZ);
SetUserPref("SI3D_NODETRANSFORM_CHILD_COMPENSATE", 0);
 
// create the envelope (connect the rig)
ApplyFlexEnv(
"_1geo.cylinder;"+
"_0rig.bone,_0rig.bone1"
);
 
// export to files
ExportModel("_1geo", project+"\\Models\\geo.emdl");
ExportModel("_0rig", project+"\\Models\\rig.emdl");
 
// new scene
NewScene(false,false);
 
// import both as referenced
SICreateRefModel(project+"\\Models\\rig.emdl", "_0rig");
SICreateRefModel(project+"\\Models\\geo.emdl", "_1geo");
 
// create a new model including both
CreateModel("_0rig,_1geo", "fullmodel");
 
// export this model again
ExportModel("fullmodel", project+"\\Models\\fullmodel.emdl");
 
// new scene
NewScene(false,false);
 
// import the fully rigged, separated model as referenced
SICreateRefModel(project+"\\Models\\fullmodel.emdl", "fullmodel");
 
// change the geometry while maintaining the connection
MakeModelLocal("_0rig", null);
MakeModelLocal("_1geo", null);
Translate("_1geo.cylinder.edge[67]", 0,0, -1.5);
ConvertToRefModel("_1geo", project + "\\Models\\geo.emdl");
 
// reload the full model
UpdateReferencedModel("fullmodel");

Here’s a link to the script file so you can download it and try it out.

I hope this helps!
Helge

So as an example, you could create a Digital Asset of an apple. In the interface that you create, you would maybe expose a control to change the color of the apple. In fact, to make it even easier, it might just be a slider that controls the color to go from green to red. You could call that control “Ripeness” if you want. You could also add a slider for controlling the size.

If you now give this asset to another artist, the only way they can change the apple is for them to use the controls you have provided. This means that they won’t be able to make the apple turn blue (accidentally or otherwise).

In a large pipeline, this can prove to be extremely useful. It means that if the TD knows what they’re doing, they can deploy assets in production which won’t get broken or changed in an unexpected way later on. Obviously, care must be taken not to take this paradigm too far and to over encapsulate the object making that asset inflexible. So research and planning for an asset’s role in the pipeline is vital to make sure that the right level of control is applied.

So how can we create Digital Assets in XSI? Natively, they aren’t supported. What do we need? We just need a way to store our asset, a method of presenting certain parameters of our choice to the user, and a way of hiding objects from various XSI editors (Explorer, etc.).

The obvious choice for storing our asset is to use an XSI model. Each model represents a unique namespace for objects and they are XSI’s current method of asset encapsulation (albeit limited).

The second one is also easy. Proxy parameters enable us to provide another location to change any parameter we want. We can also use conventional parameters and then link to them using expressions. While this method might not be quite as nice as a fully customized interface, it will do for this article. Other options might include using an HTML page to display controls to drive parameters, or an ActiveX control, etc.

So that just leaves us with hiding objects from the various XSI editors. To do that we use this:

obj.SetCapabilityFlag( siNotInspectable, true);

The SetCapabilityFlag() method can be found on the ProjectItem object, which occurs near the top of the class hierarchy of the SDK. This means that a large number of objects support this method, including mesh objects, operators, clips, materials, properties, clusters, and many others. In addition, the parameter object also has this method, despite not inheriting from the ProjectItem object.

So here’s an example implementation of the apple Digital Asset.

In the end, I put in four controls.

The Deform parameter drives the amplitude of a push operator connected to a weight map to add variation to the shape of the apple. Since I didn’t lock the weightmap, you can still modify it using the weight paint brush to change the shape.

The Ripeness parameter drives an expression to control the color in the render tree (you need to render the apple to see the color change). Note that I had to use a “Vector Share” via a “Vector To Color” to drive the diffuse color, as XSI doesn’t let you put expressions on color parameters.

The Size parameter uses some basic rigging to change the size of the apple without changing the size of the stalk.

And finally, the Resolution parameter directly drives the Geometry Approximation to alter the subdivision level.

After hiding all the properties that I didn’t want the user to see, it looks like this in Explorer:

Note that I’ve set the Explorer view to show “Local Properties” so that we don’t see any inherited properties that would otherwise appear there in italics.

To hide the various properties that I didn’t want to see, I used a simple script that can be run from “Model->Get Property->Digital Asset Tools->Pick Objects to Not Inspect“. You can download this script below. When you run the tool, you pick items in Explorer that you want to hide with the left mouse button. Right click to finish and see them disappear. Note that I haven’t supplied a tool to make things re-appear again, so make sure you know what you’re doing!

Okay, so this all seems great. However there are a few gotchas that you have to be aware of:

• Once you’ve hidden something, you’ll have to use scripting to get it back again. There’s no other way.
• Don’t try to hide shared properties (e.g. ambient, the Scene_Root’s material, etc.) as it will hide all instances of that property. For example, if you hide the shared ambient property, you’ll find that the “Ambient” button in the Render toolbar won’t show the PPG to let you edit it.
• Only hide an actual object when you’re certain it’s not needed. In my example, if the user selects the Apple mesh and presses H, they can always unhide it by selecting it in Explorer and pressing H again. If you’ve hidden the actual object from the Explorer too, then the only way to get it back is to use the “Unhide All Objects” from the Display menu.
• Hiding individual parameters can be great for hiding them from editors such as the graph editor. BUT, be very aware that you’ll no longer be able to access that parameter from scripting using many of the conventional methods. This may well break numerous common operations in XSI, so make sure you research the implications of what you’re doing. You have been warned!
  (In fact, you can still access the parameter to unhide it again, but you have to do it by pushing it’s name into the Items property of an XSICollection)
• Duplicating the DigitalAsset model with Ctrl-D will lose any expressions that you’ve set up, unless you’ve enabled “Copy Animation” in the Duplicate Options. This can cripple your Digital Asset if it relies on expressions to do some of the work.

The most important thing to note, is that (to my knowledge) this technique has not been production tested inside XSI yet. This is a fairly non-standard way of working in XSI, and it isn’t something that Softimage would be expecting you to do. Hence there may be other gotchas that I’ve not found yet that could invalidate this way of working.

Having said that, it’s definitely a cool technique, and I hope that this or a similar type of workflow will be acknowledged or supported by XSI in the future.

I’ve uploaded the asset as an XSI 5.0 model (both the unhidden and the final versions of the asset), as well as the script for making your objects and properties hidden. To install it, you need to copy the script to your user/application/plugins folder.

DigitalAsset.zip

(Disclaimer: I’ve given fair warning during this article about the dangers of hiding things, so I accept no responsibility for any losses you may incur! Please take care.)

1

Application.LogMessage("Whatever")

Am I tired of writing this in my XSI Python scripts you think? In Python, variables are basically pointers to the actual object and everything in Python is an object, functions included… Hmmm…

Try using this at the top of your python scripts:

1
2

xsi = Application
pr = xsi.__getattr__("LogMessage")

Now you can do:

1
2

xsi.Whatever(attrib)
pr(whatever.Property)

instead of

1
2

Application.Whatever(attrib)
Application.LogMessage(whatever.Property)

All of this with absolute minimal overhead! My wrists will be thanking my little brain fart in twenty years!

To which I reply: are you really a programmer if your ubber-complex program fits in twenty lines and the heavy lifting is done by a library / framework? This friend of mine is a very qualified and efficient .Net programmer.

— — — — —

I was having a drink with a couple of buddies last night and told this story. One of the guys spontaneously provided a heartfelt answer to the debate. He had obviously thought about this before…

The purpose of a programmer is to have the buisness logic of a client be executed by a computer. By client this can be a paying client of a software company or it can be the guy next to you in a department who needs a tool. In this context, no one cares – especially not the client, how this execution is acheived. As long as the buisness logic is executed by a computer within the prescribed development timeframe and the alloted budget the client should be satisfied. The debate on which tools to use, because this is essentially what this boils down to, is purely academic and is in the greater scheme of things worthless — nobody cares, as long as the buisness logic is taken out of their hands.

Hmmm… Score: 5, Insightful.