Batch Scripting (XSISDK)
It is possible to run XSI from the command line and have it execute a script or render job without launching the full XSI UI. This can result in fast execution of batch processes and be very useful for render farms and other scenarios where the server may not have a display.
This page contains tips for writing scripts that work well in batch mode.
For JScript and VBScript you can pass arguments a method that you wish to execute. This is not currently supported by Python. The workaround is to use a simple wrapper script in jscript or vbscript that will get the arguments and pass them directly to the real Python script.
The -uiscript flag lets you launch the XSI UI, run a script and then shut down XSI. Hence it is a batch script that runs with the normal XSI UI. This will be a little slower than a batch script with no UI but in some cases it can be necessary.
Some scripts are not suitable for execution with the -script flag because they have some UI dependency. An example scenario includes code depending on OpenGL, such as the Object Model call Texture.GetTransformValues.
Also some complex rigs or simulations with lots of operators and expressions may not work in the same fashion in batch mode because of XSI's lazy evaluation design. For example, some operators may not be evaluated if the object that it outputs to is not actually "pulled". Often this can be fixed for batch mode by being sure to read the affected objects from the object model. In some cases the "Refresh" command can help also. However using "-uiscript" can be a quick way to solve this scenario because the presence of the XSI UI will help ensure that the batch execution is the same as a normal UI interactive execution.
Avoiding UI Dependency
A batch script should not attempt to launch user interface that would block the script execution.
However it is safe to use XSIUIToolkit.MsgBox because that will automatically detect batch mode and do nothing.
In your own scripts you can make any user interface conditional based on the XSIApplication.Interactive property.
A good design pattern for scripts that need to execute with UI or with scripting is to design a low level command that has no UI and can be called from scripting. This same low-level command is also called from a high-level command that includes the UI.
For example a typical export plugin would have two commands:
ExportAcmeWithUI() ExportAcme( in_filename, in_options )
ExportAcmeWithUI would show a user interface to get the filename and other options, then call ExportAcme. A batch script would always call ExportAcme() directly.