Built-In Functionality (Comparing - Part 2)
So far this article has covered how to write your own scripts. However the real purpose of most scripts is to tap into XSI’s 3-D content creation functionality. To do this you need to understand XSI commands and its object model.
|Table of contents|
Mel and XSI Commands
All Maya functionality is exposed in MEL as commands. Each command tends to support different modes and many flags so the same command might be used to create an object, query an attribute on an object or set an attribute on an object. The syntax for calling a Maya command is similar to the invocation of a process from a command line, in particular each argument is specified with a hyphen, the name of the argument and finally the value of the argument.
For example this call will create a plane:
polyPlane -w 1 -h 1 -sx 10 -sy 10 -ax 0 1 0 -tx 1 -ch 1;
This is an equivalent call in XSI:
CreatePrim( "Grid", "MeshSurface" ) ;
Invoking an XSI command uses the same syntax as invoking a script procedure, with the arguments specified in a strict order. Some arguments may be optional, for example CreatePrim also supports a third argument for the name of the new object. To create a grid that is named “MyGrid” the following XSI command is invoked:
CreatePrim( "Grid", "MeshSurface", “MyGrid” ) ;
There are over 1000 XSI commands. Fortunately they are documented, along with each argument, in the Scripting Reference that gets installed with XSI's SDK.
In Maya, actions performed in the user interface result in MEL commands being executed. These are logged and can be replayed. It is possible to turn on a mode that logs even more commands as they are executed.
In XSI, practically every action that changes the scene results in an XSI command being executed. These are logged using the syntax of the currently active scripting language. Purely user interface oriented actions do not log anything (for example opening a Property Page). Calls to the XSI Object Model are not logged.
The XSI Object Model
XSI Commands are powerful for building content inside a scene, and automating repetitive tasks. However XSI commands are not suitable for reading the content of a scene or developing really advanced scripts. For this purpose XSI also exposes an Object Model. With this API the scene content is exposed as a hierarchy of different objects, each of which exposes data and functionality. If you are familiar with other scriptable Object Models, such as the Document Object Model of Internet Explorer, or have experience with C++, then the XSI Object Model concepts will be easy to absorb.
For other users it might be helpful to imagine this analogy: A user of XSI can use the scene explorer to search through a scene, and can click on the "+" icons to expand the objects nested under each object. All the content of the scene is available in this tree view, and any part of the scene data can be found by starting at the scene root and “drilling down” level by level. Once the data is found, you can right click on its representation in the explorer to display a context menu. The options displayed inside the context menu will vary depending on the type of data, and if an action is invoked from this menu then it will directly affect that node (even if that node is not part of the current selection). The XSI Object Model can be thought of as a representation of the scene explorer for programmers. Each item that makes up the scene is called an “Object” and there are different types of objects that correspond to the different types of nodes shown in the scene graph. In addition, each object exposes a set of methods, which are like the actions that appear in the context menu. For example on a Parameter it is possible to add an Fcurve (though the AddFCurve method), and on a ChainRoot it is possible to add a bone (through the AddBone method).
Even more useful than the methods that can be performed on an object are the properties, which provide a way to read or write the actual data of the object. Again the data that is available depends on the type of the object. For example a Parameter has a Value and a Particle has an Age and a Mass. All sorts of vital information is exposed in this fashion, including all the geometry data, simulation state, all the values of any controls shown on the Property Pages, the interconnections between objects and so on. Script writers familiar with C++ can think of these properties as the member variables of the object.
It is important to mention a problem of terminology that can confuse script writers. Each object in the XSI Object Model exposes data through something called a Property. However XSI also has a specific type of object called a Property. These are very different concepts and depending on the context it should normally be clear which type of property is being referred to.
Scripts will often include a combination of commands and object model code.
Useful Commands and Object Model methods
- In MEL the commands whatIs and objectType are used to provide information about a variable or object. In XSI use Application.ClassName(), SIObject.IsClassOf(), SIObject.Type and XSIUtils.GetVariantType().
- In XSI use Application.Platform to determine what platform the script is running on. You can access environment variables via XSIUtils.Environment. Use XSIUtils.LaunchProcess() to launch external applications.
- An equivalent for many uses of ls is calling ActiveSceneRoot.FindChildren(). The equivalent of “ls –selection” is XSIApplication.Selection.
- The translate, scale and rotate commands in XSI are similar to the move, scale, and rotate commands in Maya.
- Comparing XSI SDK and Maya SDK
- Scripting Basics (Comparing - Part 1)
- Built-In Functionality (Comparing - Part 2)
- Architecture (Comparing - Part 3)
- Custom User Interface (Comparing - Part 4)
- C++ Support (Comparing - Part 5)