We love third party renderers. There, we said it. We love third party renderers - especially the kind with rapid development cycles that throw us new things to play with on a regular basis, rather than having to wait for years for negligible improvements. You know what we mean.
As it turns out though, they do come with some issues. Release cycles will inevitably not sync up with project cycles, and it's never long before you end up wanting to upgrade to the latest version, but being held back by a current project which uses an older, incompatible version. Most likely you'll want to use the two versions concurrently, one for each project.
The good news is that Softimage's workgroups simplify the process. The bad, that managing them manually is tedious at best, very dangerous at worst. From a usability perspective, it is unrealistic to expect every artist to be constantly ensuring that they have the right workgroup connected for their current project. At some point, someone will forget and work in the wrong one- guaranteed. They'll be happily shading away for hours, if not days, until they realize that all their work is lost when reverting to the correct version. To insult to injury, even if they don't forget, switching workgroups with renderer plugins in a Softimage session creates “instabilities”, with an inevitable crash on the horizon. Oops.
To work around this as painlessly as possible, at Kettle we've implemented a tool that manages the user's workgroups based on their active project, requiring zero of their input and with minimal interruption of their workflow. The system doesn't claim to be perfect or applicable to every established pipeline, but we hope it gives you a nudge in the right direction when researching your own solution.
Setup
First, we should share a little info about the general setup at Kettle.
- All user machines run Windows 7
- All users have local preferences
- We use a dual workgroup setup. Softimage is permanently connected to a softimage version specific global workgroup, which contains the essential pipeline plugins, including the workgroup switcher. This plugin dynamically switches the connected project workgroup containing the renderer plugin, as well as other project specific plugins In later versions of Softimage, the ICE Kinematics workgroup is also connected.
- Softimage version specific global workgroups are kept in a fixed network location: [repositorypath]\workgroups\softimage\global\[version]
- Project specific project workgroups are kept in a fixed location in each project's directory tree: [projectpath]\workgroups\softimage
Switcher
The interactive workgroup switcher has two elements: the Softimage plugin and a standalone relaunch script.
When one of the plugin's events (onStartup, onBeginSceneOpen, onEndSceneSave2, onEndSceneSaveAs, and onChangeProject) are triggered, they check whether the currently applied workgroups match those expected for the scene. If not, they will raise a flag held in the plugin userdata.
This flag is monitored by a timer event which, when triggered, will gather the necessary data to restart Softimage. This includes a references to the Softimage application itself, the scene to be reopened and the required workgroups. It will then pass this data to the standalone launcher script in an external process, and quit Softimage.
The launcher script, in turn, monitors Softimage's process ID for a shut down, after which it rewrites the local user preferences file to include the correct workgroups. It then relaunches Softimage with the -scene tag, picking up the workgroups from the preference file.
Notes
Why bother with the flag and timer setup, rather than just going straight for the relaunch from each event? The onBeginSceneOpen event needs to return a 'true' value to cancel the scene open process, which it won't return if the quit command is issued from within itself. As a result it would opent he scene before quitting Softimage, wasting a lot of time on heavy scenes, and generally being an annoyance even when not.
Shutting down Softimage while its in use, not giving the user any choice in the matter, is a pretty draconian approach. The possibility of allowing a user to override the switcher has come up. In our opinion however, the switcher only kicks in at milestone moments, such as when the user saves a scene or starts a new one, and therefore doesn't catastrophically break the user's flow. The risks associated with working with an incorrect workgroup setup, on the other hand, carries a lot of weight. That said, adding a user prompt is easy, so feel free to make up your own mind on the matter :]