Kettle Overscan is a Softimage plugin I wrote aiming to simplify the process of over/underscanning renders. It applies a property to the camera from which the user can overscan a render by a given percentage or discrete pixel amount. Bugtested and refined at work, so it carries the name, but they’ve graciously allowed me to share it with the community :]

Usage

Select a camera and use the “Application.kettle_overscan_apply()” command. The camera must be in use by a pass. Set the base width/height if necessary, and adjust the overscan value. Hit the “Set Output Res To Passes” button, and you’re done

Settings

Notes

• - The overscan property overrides the camera property’s field of view controls. As a result, changing the FoV in the camera PPG while it has an overscan property applied can cause badness. Try to avoid it, and change the base FoV in the overscan property instead.
• - I strongly suggest using the kettle_overscan_apply() command to apply the property, rather than applying it directly, since it checks for all manner of badness such as duplicate properties.

Download & Installation

Download

This is a self-installing plugin, so just drop it into the plugin folder of one of your workgroups (eg. the user workgroup – C:\Users\yourusername\Autodesk\Softimage_version\Application\Plugins), and you should be ready to roll.

Requires: Softimage, Python.

Future

Currently on the to-do list, for when I get some time to breathe:

• - Arbitrary overscanning/cropping, doing away with the enforced aspect ratio.
• - Support for stereo cameras – not something I’d needed so far, so I hadn’t thought of it, but there’ve been requests.

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.

As a result, I found myself developing a plugin at Kettle that would manage the user’s workgroups based on their active project, requiring input and causing minimal interruption to their workflow. This approach doesn’t claim to be perfect or applicable to every established pipeline – I’m aware that there are a number of other companies in the same boat with their own setup – but I 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.
A timer event monitors the flag and, 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 passes this data to the standalone launcher script in an external process, and quits 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 relaunches Softimage with the -scene tag, picking up the new workgroup setup 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 did come up. In my 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 someone working in an incorrect workgroup setup because they couldn’t be bothered with a 20 second interruption, on the other hand, can be pretty heavy. That said, feel free to make up your own mind on the matter – a user prompt is dead simple to implement :]

This is a lightly edited repost from of an article written for Kettle’s own blog, see the original here.

For my main contribution, check out the astronaut clip, where I did all the exterior modeling for the ship. I’ve gotta say though, in the final edit it does flash by a bit quick. Besides that, I did some bits of compositing on a few of the other sequence, but they are a bit more scattered about and hard to point out. Grumble.

Big stuff went down last week, as the much anticipated switch finally happened and the lights went off at JS3D, making way for the emergence of the brand new Kettle. This should answer some questions – awkwardly fended off over the past half year or so – about the naming of the shaders and tools we’ve been sharing.

Check out the spankin’ new site and come polish our egos –  www.kettlestudio.co.uk

Furthermore, we’ve also got ourselves a new colleague. He’s called Kasper, and he finds himself in charge of company morale, chewing CAT5 cables and begging for a share of our lunches.

Oh, you know you’re jelly :]

All the 3D, from the huge building to the graceful jellyfish-like devices that guide the viewer around it, was done at Kettle. Despite the fact that the judges were undoubtedly blown away by the amazing use of flash rollover events on the site, I believe we may be able take some credit here too :]

As part of the team, I did the majority of the interior shot layout and camera work. I also modelled, rigged and animated all the viewing devices.

The Kettle AOV plugin is an in-house further development of Jules Stevenson’s AOV Setup script, widely used by the Softimage/Arnold community to speed up framebuffer setup on passes. The plugin further simplifies the process, as well as making it easier to customize the applied framebuffers.

Kettle AOV spawns a live custom property under each selected pass, and allows you quickly and easily add and remove specific or preset groups of framebuffers, bypassing a tedious manual setup. The corresponding render channels are automatically created under the hood as necessary.

It supports all the standard Arnold framebuffers, plus those specific to the open source Kettle Uber shader.

Requires: Softimage, Arnold Render, Python

Documentation
Download

Quite literally too – pushing around cubes for the old school 8 bit feel. Lovely ;]

Wasn’t to keen on the concept art here – I had to work off and keep consistent with a very bland existing model – but I cleaned it up and threw in as many animated little mechanical parts on the periphery and under the hood as I could get away with to give it some interest in action. In combination with the shiny lab and the projected virtual environment, it’s come out pretty neat! :]

nbLightLister is a little tool for Softimage written in Python, in the spirit of 3ds Max’s light lister. It gives the user an easy overview of all the lights in the scene for more comfortable comparison and tweaking of the main features. The user can choose to view either all or a selection of the lights in the scene. Currently, the exposed parameters are the render visibility (On), name, intensity, color, shadow on/off, umbra, falloff on/off, falloff mode, falloff exponent and the falloff start and end.

nbLightlister only supports MR lights.

The download comes as a zipped Python self-installing plugin. Just drop it into your user or workgroup plugins folder and you’re good to go; the link will lodge itself in the View menu.

Download