Myself and 6 others are working hard to put together the first meeting on the 29th May. It will be held at The Jerusalem Bar in Soho, right underneath Passion Pictures.

How can you get involved? Well, there are three things you can do:

1. This one’s compulsory! If you want to come along on 29th May, make sure you register for the event using the “Register” button on this page.
2. Let us know if you want to present something at the meeting. It’ll be quite informal, and you’ll just be talking to people crowding around you, rather than an entire room. It’s more like a show and tell, it wouldn’t have to last more than 15 minutes, and others will be happening simultaneously as you do yours. It’ll be fun, nothing to be scared about!
3. We want to show off some of the work you’ve been doing by putting together a Softimage reel to show at the event. Get in touch if we can use some of your gorgeous graphics in the video.

One last thing. Tell everyone!

For more information about the event, including registration information, please visit this page.

Twitter: @SIC_London
Facebook: http://www.facebook.com/pages/SoftimageCreatives/356159824418094

It’s worth mentioning that ICE can do a whole lot more than just particles. Here’s a quick list off the top of my head:

• Mesh Deformation
• Animation of object transforms (ICE kinematics)
• Rigid body simulation
• Cloth simulation (via Syflex ICE nodes)
• Procedural modelling (as of XSI 2012)
• Fluid simulation (with built in Lagoa Multiphysics, or alternatively emFluid)
• Point rendering (via emRenderPointCloud)

So there really is no limit as to what you can do with ICE, and the best thing about it is that it’s just about the fastest thing out there.

If you’re into programming, then it also has a great SDK which allows you to develop your own multi-threaded ICE nodes, just in case there’s something you need to do that it can’t support natively. (So far, I’ve only needed to do that once when I had a particularly complex bit of array sorting and processing to do).

• Notes About This Tutorial
• Stage 1: Introduction
• Stage 2: Setting up suspension dynamics
• Stage 3: Constructing the main rig
• Stage 4: Rigging the CoG (center of gravity)
• Stage 5: Adding pitching motion to body
• Stage 6: Attaching the 3D mesh to the rig
• Stage 7: Animation and Automatic Steering

Notes About This Tutorial

 
This tutorial was written for the November 2008 of 3D World magazine (issue 109). It shows how to create a rig for a 4 wheeled vehicle that uses spring dynamics to simulate suspension movement.

Originally companion scene files were supplied for XSI version 6.5, along with a high resolution model for the vehicle. Since I don’t have the rights to distribute the model, I’ve replaced it with a (very ugly!) low resolution proxy. As a result, two of the scene files have been modified using XSI version 9.5. The original start scene is still in XSI 6 format, so you’ll be able to follow the tutorial if you have an old version of XSI.

Below is a video of what you can expect to create:

For clarity I’ve also uploaded a step-by-step video that shows the process. To make it easy to follow the article and watch the video at the same time, you can click the following image to open it in Vimeo in a new window:

One other side effect of recreating the tutorial for XSI 9.5 is that some of the simulation settings have changed. The tutorial text below has been updated to reflect the changes, but the step-by-step video has not. As a result, the old settings for the spring constant (14.0) and spring damping (1.0) will be seen in the video instead of the new settings (80 and 6 respectively).

A few other minor changes have been made to the text, but otherwise, it is exactly as printed in the original magazine. As such, the explanations are quite brief as there were constraints on the number of words. If you feel you need better a explanation of any of the steps, please leave a comment.

If you have any problems viewing the screenshot images at high enough resolution, either go full screen with your browser, or right click and select “Open Link In New Window”.

I’ve provided the following companion files as a single downloadable Zip file:

• Hummer.emdl
• WheelTurnOp.js
• vehiclerig_start.scn
• vehiclerig_step16_XSI95.scn
• vehiclerig_final_XSI95.scn

If you want to follow along, then at the very least, you need to start with the “vehiclerig_start.scn” scene file.

XSI Tutorial Files V1.0 (881 Kb)

Introduction

Designing a vehicle rig to accommodate every possible situation is a complex task, if not impossible. In most cases, you would have a specific rig for a specific set of circumstances. This has parallels with how cars are used in the movie industry where they might have several different versions for specific stunts, as well as a “hero” car for close up work.

The job of the rigger is to put together a system that will allow the animator to concentrate on creating a performance. The animator should never have to worry about the technical aspects of a damped spring system. If a rig is constructed properly, it will automatically respond and recreate the suspension’s subtle dynamics.

The rig that you’re about to make is designed to work for fairly flat surfaces. It has suspension based on a physics simulation which allows it to react to the underlying surface in a realistic way. There is a system to roll the car from front to back as it accelerates, and the vehicle will even steer automatically.

This tutorial is about the assembly of the physics simulation and constraints that make up the suspension, but it’s important to realise that there still leaves a lot to be desired from an animator’s point of view. For example, a rigger would typically provide a synoptic view (a special HTML driven toolbar) or a custom parameter page for the animator to easily access key controls in the rig. An animator may have to spend a huge amount of time with the rig, so it’s the rigger’s duty to make sure that it is as friendly to use as possible.

Also included is a free plug-in that I wrote specifically for this tutorial to rotate the wheels correctly. It’s a very simple script and I would encourage anyone thinking of becoming a TD or rigger to take a look and attempt to understand how it works. The script is fully commented to assist you as much as possible. Step two of the tutorial will take you through the installation process of this plug-in.

Stage One: Applying the wheel turn plugin

1. Start XSI and load the vehiclerig_start scene file. The scene already contains a basic hierarchy of the vehicle and wheel rig, as well as a simple terrain for testing the suspension later. Press [9] to open the schematic to see the rig structure. At the moment, we only have a rig for one wheel. We will duplicate this later for the other wheels after we have rigged it.
   
2. First we need to install a plugin for making the wheels turn correctly. Go to File > Plugin Manager and expand the User Root folder. Right click on the Plug-ins folder and select Explore from the menu. Copy the WheelTurnOp.js file from the downloaded files (see above) to this location. Click the Update All button in Plugin Manager and close its window. You now have a new menu called CarRigging.
   
3. The plugin keeps track of where the wheel has moved from previous frames and applies the correct rotation to the Wheel_Rot object. In the schematic view, first select the orange Wheel_Rot object and go to the new CarRigging menu at the top of the screen. Select the Apply WheelTurn Op option from the menu and then, in the interactive picking session that starts, pick the green Wheel_Steer object. Set the Radius parameter for the operator to 3.75.
   

Move on to the next page to continue.

Hope you find it useful.

Common Houdini Surface operators (SOPs)

Common Houdini Expressions

You can find the full list of expressions here:
http://www.sidefx.com/docs/houdini11.0/expressions/

Houdini expressions also contain the common mathematical functions that are found in most scripting and expression languages. Here are just a few:

sin, cos, tan, asin, acos, atan, atan2, abs, pow, sqrt, ceil, floor, atof, dot, cross, deg, rad, exp, frac, hsv, rgb, min, max, log, log10, round, substr, strreplace

Note: Trigonometric functions accept angles in degrees.

The modulus operation is achieved using the % character, and boolean logic is achieved using the standard C operators, i.e. <. >, <=, >=, ==, !=, !

Common Houdini Expression Local Variables

Important: The following variables are NOT available in every operator. Each operator has its own local variables, and you can find which ones in Houdini’s help documentation. The ones listed here are the ones you’ll most commonly encounter.

• Introduction
• Why use Cinestyle?
• Video noise in dark regions
• What about taking stills?
• Are there any disadvantages?
• Installing Cinestyle
• Setting up the Canon 5DMkII
• Shooting with Cinestyle
• Post processing the footage
• Working with LUTs
• What about Linear Colour Space?
• Where do we go from here?
• A final plea

Introduction

If you haven’t seen it already, Technicolor have released a custom Picture Style called Cinestyle for the Canon DSLRs.

http://www.technicolor.com/en/hi/cinema/filmmaking/digital-printer-lights/cinestyle

 
Apparently Technicolor have been working on this for the last year in an attempt to bring the Canon DSLRs more in line with other digital film cameras such as RED and the Alexa. The Cinestyle profile produces a very flat looking footage that retains a lot more detail in the darker areas. Technically speaking, it encodes the images received from the sensor into log colour space. Anyone used to working with raw footage from film will recognise the flat grade look to the footage. The aim is that it produces footage that is much easier to colour correct while retaining as much quality in the image as possible.

This post is an attempt to try to collate and filter as much up to date and correct information about Cinestyle and the practicalities of using it with the 5D MkII. There seems to be a lot of misunderstanding out there about what this is all about, particularly when it comes to working with lookup tables, or LUTs. (Nobody’s perfect though, so please leave a comment if you think I’ve got something wrong myself!)

Much of this information I’ll be sourcing from this thread on the Cinema5D forum. I’ll try to provide links as I go through to give proper credit and so that you can read the posts for yourself. If there are any dead links, please let me know in the comments.

Why use Cinestyle?

So first thing’s first; what are the benefits of using Cinestyle? Well, shooting in log colour space means that you retain more information in the darker and brighter areas. Note, that this doesn’t mean that you’re suddenly achieving greater dynamic range. The chip on your camera hasn’t changed and so you can’t magic dynamic range out of nowhere. All it means in practice is that you are getting better detail in the dark and light areas within the existing dynamic range.

All this messing around with the colour space is done before the lossy stages in the camera i.e. H264 compression (Source: post by Matt Thomas) which, of course, makes sense as otherwise it would be further degrading the signal.

The thing worth noting about H264 compression is that it is most aggressive at the low and high ends of the luminosity range, so by using the log colour space, it is effectively moving the valuable colour information away from the nasty compression artifacts. Again, Matt Thomas explains the concept very well here. He says:

The principle behind CineStyle is to move your shadow details up, away from the more destructive shadow region, which the H264 CODEC will damage more aggressively. By moving your “blacks” up into the lower mids, you will have more compressed data devoted to subtle gradations from the h264 CODEC. The same is true for highlights. By keeping the contrast very low, it allows for your highlights to be moved further from the destructive part of the h264’s white points, which, like the black points, have much less detail allowed by the CODEC than mid tones allow.

So I decided to put it to the test.

Video noise In dark regions

The following images illustrate the big advantage of using Cinestyle with video. It’s designed to test the amount of noise in the dark levels of the image.

The image on the right shows a still from the video output from the camera when Cinestyle is enabled. You can see, compared to the next set of images, the low contrast here produced by Technicolor’s picture style.

Cinestyle picture style (no LUT)

Once the lookup table is applied (in the right hand image below), the result is very similar to the video produced by the Normal picture mode (below on the left). More info later in this post on how to apply the lookup table.

Normal picture style

Cinestyle picture style with LUT

This is where things get interesting. If we now apply a Exposure filter in After Effects with a value of +7.7 to both images, we get the following:

Normal with +7.7 Exposure

Cinestyle with LUT and +7.7 Exposure

You can see, even in the thumbnails, that there is noticeable banding in the image captured from the Normal picture style image (to see it more clearly, right click on each image and select “Open Link In New Window”). It’s pretty obvious that the Cinestyle video is giving us much more information in the dark areas.

What about taking stills?

Okay, this bit was a surprise… If you take a picture using the Cinestyle mode while using Jpeg as your storage medium, you get the flat low contrast appearance in the image. All fine so far. What is surprising however, is that if you set the 5DMkII to store RAW, there is still a subtle yet noticeable difference. Usually, changing picture mode (even switching to black and white Monochrome mode) has no effect on the RAW image at all. However, in this case, something interesting is happening with Cinestyle.

With the two images below, at first glance the RAW doesn’t appear to be particularly affected by Cinestyle. RAW files basically ignore most of the camera settings like picture profiles, white balance, etc., so this would be as expected.

Normal picture style

Cinestyle picture style

 
However, if we now overexpose both images, we get this:

It’s a very subtle difference which you probably won’t notice unless you view the full size images side by side (again, just right click on each image and select “Open Link In New Window”). If you look in the darker areas, you’ll notice that the Normal picture profile hue tends towards red in the darker areas, whereas Cinestyle appears to retain the correct hue through to the darkest point.

Wow. So Cinestyle seems to be doing something genuinely funky with the colour processing pipeline in the 5DMkII. Something that none of the other picture styles do. This only goes to confirm that Technicolor must have been working very closely with Canon to implement Cinestyle.

Are there any disadvantages?

Yes, possibly. In tests I’ve done, it’s quickly apparent that there’s a black offset. A large number of posts online suggest that black is mapped to a value of 16. In my test however, it only appeared to be around 8. This would seem to be confirmed by the Cinestyle LUT. Going into After Effects and making a solid layer at RGB <8,8,8> and applying the Cinestyle LUT (see later), the resulting RGB value that the LUT returns is <1,1,1>, whereas an input of RGB <7,7,7> results in <0,0,0>.

If you want to see the black offset for yourself, the test is very easy to do on your camera and is noticeable just looking at the LCD viewfinder. Just leave the lens cap on and take two short bursts of video, one with Cinestyle, and one in Normal mode. Press the play button and flick between them using the front dial, you’ll be able to see that the black is obviously lighter in the Cinestyle footage. When I tested the colour values in After Effects, it gave values around 7 or 8 as the minimum.

Similar tests with overexposure showed that the white was not offset, i.e. with full exposure, it used the maximum white value of 255. The offset in the black helps to avoid the more destructive compression of H264, but it also means that we’re losing colour resolution. This could result in banding issues if the colour grading is pushed too far in the mid tones where there might not have been issue before. For a good example of this, see this post by Richard Crook. Also, check out this video which discusses some of the problems involved using flatter colour profiles.

Which then leaves us in a bit of a dilemma. Should we be using Cinestyle at all? Unfortunately, I don’t think there’s an easy answer. I’d say that it depends on what you’re going to shoot. As Richard says in a later post:

If you are shooting a situation like, for example, in a forest…then banding is a moot point because there is so much texture it doesn’t matter. But shooting a low dynamic range subject like the sky or a wall, both with subtle gradients, a flatter profile like Cinestyle isn’t a good choice.

That makes sense to me. From a post production point of view though, it’s a bit of a pain, because if the camera operator is switching between different colour profiles on a per shot basis, then that’s one more thing you (or the clapper loader) has to keep track of.

Installing Cinestyle

To install the Cinestyle profile, you first need to download it from Technicolor’s website.

Once you’ve got that, you need to make sure that you have the EOS Utility installed on your machine. It’s supplied on a CD that came with the 5DMkII, but if you don’t have it handy then you can download EOS Utility from Canon US. The only issue with downloading it, is that it’s engineered by Canon to be an update-only install (why do they make things so hard for us!!). Luckily, it’s quite easy to turn the update installation into a full one. Full instructions can be found on Keith Cooper’s photography website.

The step by step instructions for installation can be found at Technicolor, but for your convenience, I’ve copied them in below.

1. Ensure that EOS Utility v2.6 or later is installed on your computer
2. Download the Technicolor CineStyle Picture Style file
3. Connect your camera to your computer using the appropriate USB cable
   Note: for the EOS 5D Mark II you may need to set “Communication” to “PC connect.” in the camera’s menu
4. Start the Canon EOS Utility
5. Select “Camera settings/Remote shooting” on the main window
6. Once the capture window opens, click the camera icon
7. Click “Register User Defined style” under “Shooting menu”
8. Once the new page “Register Picture Style File” opens, select one of User Def. 1, 2 or 3 at the top of the new page
9. Click the open file icon
10. Select the CineStyle.pf2 file you’ve just downloaded
11. Click on OK

Setting up the Canon 5DMkII

There are a couple of subtle issues that you should be aware of to maximise your the quality of your footage. Neither of them are killers, but it’s a good idea to be aware of them.

The first thing to know (and the source for the following explanation is a great in-depth article at Josh Silfen’s website), is about how the 5DMkII works with the ISO setting. To paraphrase Josh’s article, the sensor in your camera has an intrinsic ISO setting associated with it of ISO 100. The ISOs that are at doubling sensitivities above this (i.e. 200, 400, 800, 1600, 3200, 6400) are also native ISO’s (derived, I suspect, from directly manipulating the way the sensor is employed). All the other ISOs are based on these and are either 1/3 stop over or under exposed.

For example, it is approximately true that:

ISO 320 = ISO 400 x 2^(-1/3)
ISO 500 = ISO 400 x 2^(+1/3)

This is a digital process after the image has been captured, and means that from a visual point of view, the pull down ISOs of 160, 320, 640, etc. will appear to have less noise. Unfortunately, the stopping down also means we have less dynamic range, as the highlights lose 1/3 of a stop as well. We end up with a trade off, and so it’s definitely something to be aware of. Please read Josh’s full article on this for more in depth information.

The other thing to know, is why you probably shouldn’t use Highlight Tone Priority. Again, Josh comes to our rescue with another brilliant post on this which you can find here. Essentially, the message is that Highlight Tone Priority doesn’t give you any extra dynamic range, and you have a little less control over exactly what the camera is capturing. You’re doing colour correction in-camera, rather than in post.

Shooting with Cinestyle

The main thing to know is not to set the exposure for your video with the CineStyle profile enabled. As Richard Crook notes in this post, going a stop either side of the correct exposure makes little difference to what you can see in the camera’s LCD screen. That’s a big change to be unaware of.

So unfortunately that means you’ll need to set up the exposure using the Normal picture style, and then switch to Cinestyle for capture. Not ideal. It’d be great if it were possible to capture using one style and preview using another, but I guess we’ll have to keep wishing.

Post processing the footage

Once you’ve taken your video, what’s the best way to process it? RareVision’s tool 5DToRGB will convert your H.264 quicktime movie into DPX files using some sort of clever processing technique to achieve better results than the standard quicktime codec for decompression.

If you’ve got a lot of files to convert, you can use this batch tool from Noside to convert multiple videos at once using 5DToRGB.

The footage that comes out of the camera looks very flat. That’s why Technicolor provide a lookup table (LUT) to view the footage with. In order to use it with After Effects, you can download for free Magic Bullet LUT Buddy 1.0. This allows you to apply the LUT to a layer as an effect. There seems to be a couple of issues with LUT Buddy crashing, but it is possible to work around the problem by converting the LUT to a different format. More information on this fix from Lars Steenhoff’s blog post.

Working with LUTs

There seems to be a fair bit of misunderstanding in the online DSLR community about what LUTs are and how to work with them. It’s understandable, as they’re not something most photographers have to deal with, so there follows a brief explanation.

In an ideal world, before manipulation in post with CGI and compositing, all footage should be converted into linear colour space (sometimes also called “scene referred” colour space). Linear colour space is where the brightness of a pixel is directly proportional to the amount of light that it received in the camera, i.e. a doubling of pixel intensity, means double the received light.

Most people are used to using images that are encoded in sRGB colour space. This has a gamma correction curve of approximately 2.2 encoded into the intensities so that it displays correctly on a monitor (which has a response curve of 2.2). But this means that for an sRGB image, if a pixel receives double the intensity in camera, it won’t be double the brightness in the image.

The problem with using and manipulating sRGB images is that a lot of mathematical operations in compositing don’t work due to the maths being affected by the baked in gamma curve. On the other hand, although we can use linear images, they don’t look very good when directly viewed on monitors and it’s very hard to make aesthetic judgements.

This is where LUTs are a big help. They allow us to view images in one colour space (i.e. sRGB), while the software processes them in another (i.e. linear). It’s a little bit like looking through a pair of sunglasses; the image isn’t being being changed, but it’s altered at the last minute for your benefit so that you can see it properly.

So in VFX, LUTs are used all the time to work with footage in linear colour space during compositing. It means that the software can do all it’s operations correctly in linear space, while we can view the result through the LUT that turns it into something that we can view properly on our monitor. In addition, we’ll often encode a grade (colour correction) into the LUT so that we can see how the final image will appear once the colourists have done their magic on it and applied the final look.

The problem with software like After Effects, is that their colour space handling is extremely confusing to deal with. Seeing as After Effects doesn’t directly support LUTs (as pointed out in the comments section, CS5 now has a plugin to apply LUTs in a similar way to Magic Bullet, unfortunately there’s still no way to load a LUT into the colour management settings), then I’d generally recommend applying LUT Buddy to an adjustment layer at the top of the main composition. As you work, everything can be viewed with this applied.

Colour corrections can be done before or after the LUT layer. In fact, you can even throw away the LUT altogether and do your own grade from scratch. It’s a little bit arbitrary for reasons explained in the next section.

What about Linear Colour Space?

That’s a very good question. The big problem with Cinestyle is that the supplied LUT converts from a log based colour space to something very similar to the original REC 709 colour space, and NOT linear. A lot of people online are saying that the LUT does convert to linear, but it doesn’t as the final result still looks perceptually correct on a 2.2 monitor. This means that it must have a 2.2 gamma correction applied to it, and so it’s probably REC 709 or sRGB.

As of this moment in time, Technicolor have not released a LUT to go from Cinestyle to linear. This is a bit of a major issue for anyone wanting to composite with this footage. In theory, it should be possible to use the LUT to convert from Cinestyle to REC 709, and then convert from REC 709 to linear, although I’ve not tested it’s accuracy yet.

Where do we go from here?

In lieu of Technicolor releasing a Cinestyle to Linear lookup table, I believe the next step is to look into measuring the camera response curve and deriving my own lookup table to convert to linear space. I believe a paper exists by Paul Debevec that illustrates this process. I’ll post a link if I can find it.

A final plea

Dear Technicolor. Cinestyle is great and opens up our ability to capture higher quality video, but it’s severely limiting if the proper technical details aren’t released to the community to allow us to use it in the correct way. The lack of a clear specification of what the supplied LUT actually does (i.e. the destination colour space) is a surprising omission in this release. Publicly releasing a LUT to go from Cinestyle to Linear would be a simple solution to this problem.

Please, give us more information!

This was taken from a question and answer session where I discussed the techniques used for the AT&T Spring commercial; a job I jointly led at our Mill New York office earlier this year.

Written for 132nd edition of Digital Media World Magazine.

Q. How does this vine growing simulation relate to or borrow from the familiar particle, flocking, crowd or even city-building simulations? If you have based it on existing software could you say what that is?

A. The vine growing simulation was created inside Autodesk’s XSI using ICE. ICE is such a fast and flexible system to use that it makes it easy to prototype a wide range of ideas very quickly. We were also rendering in XSI, so keeping the majority of the work in a single 3D application helped to simplify the job considerably.

The system itself was constructed from scratch. It used particles to crawl over the buildings leaving ICE strand trails behind that represented the vine growth. After the vine particle moved a random distance, a stalk particle was generated and a leaf was attached to the end of it. As the stalk grew, the leaf would proceed through an animation to represent the emergence of the leaf from the bud. Every now and then, a new vine branch would get generated and the process repeated recursively up to a limit. If we needed flowers on the vines, then we’d just occasionally swap in a flower instead of a leaf.

There were only a couple of shots in the AT&T commercial that required seeing the vines and flowers grow together, but the growing simulation was still used for many of the static shots like Chicago’s Washington Street as it provided a nice natural coverage of the buildings. Particle systems based on volume emission were used for many of the wider shots and also for where the flowers and leaves needed to look a bit more bushy.

For some elements we used the Ivy Generator written by Thomas Luft (University of Konstanz). It’s a free to use application (even for commercial use) for creating ivy vines and leaves. It’s available to download from his own university webpage (http://graphics.uni-konstanz.de/~luft/ivy_generator/). Initially we thought that we’d use it on most of the shots, but we had to be careful to make sure it matched the look of our own ivy and it didn’t offer us quite as much control to art direct the growth of the ivy as our own proprietary system. In the end, we mainly used it for dangling ivy from bridges.

Finally, when we needed precise control over the placement of vines, bezier curves could be hand drawn and snapped onto the underlying geometry. ICE set-ups would use these curves to generate renderable vines and scatter leaves and flowers. That was a big time saver and it really helped to blend in some of the particle generated elements. It was kind of fun drawing them on with our Wacom tablets so it made for a nice break from tweaking the simulations.

Q. How are plates chosen that will work well with the application?

A. The plates weren’t chosen for the ivy simulation as it was still in development at the time of editing. However the directors (Josh and Jonathan Baker from TWiN) had a clear vision of exactly how far the ivy and the flowers should have grown on each shot. It made life a lot easier during the layout process as it minimised experimentation. Some of the shots were nudged or swapped around in the edit to support the narrative as the work progressed. Having this flexibility in the edit meant that we could let the plate dictate to some degree the composition of the ivy and helped it feel more natural.

Q. How do you give the application enough 3D information about the scene so it knows the coverage it needs to achieve?

A. As you’d expect, the first process was to track the plate. We found that we needed to get a similar level of accuracy as if we were tracking a plate for stereoscopic 3D because we needed to get a tight geometry match. No cheating was allowed! Once we’d built the model, positions were specified for the ivy to sprout from. The ivy grows simultaneously from multiple locations but each root can be given different behaviour, such as speed of growth, duration, and direction. It gave us a lot of control over the layout. Additionally, hints, in the form of arrow shaped objects, were placed to act as a force field to guide the way the ivy crawled across the surface.

Q. what other essential information does it need about the scene and about the plants, flowers etc before it can start?

A. The most important controlling factor over the plants is the direction that the underlying surface is facing. Everything about the growth and orientation of the leaves and flowers is based on that. The model had to be adjusted in several cases to get the desired response. Some shots benefited from the flowers being made to turn slightly towards camera which helped to increase the sense of volume to the foliage.

Q. Can the density be controlled?

A. Being essentially a recursive system, the ivy simulation was very sensitive to small changes in its setup, which meant it was necessary to try to keep everything about the inputs to the simulation as consistent as possible. For example, we were very careful to keep the scale of the scenes the same so that once we achieved a look that we liked, we could leave all the controls for leaf emission and density alone. This simplified everything considerably and meant we could achieve a consistent look across all the shots.

The important aesthetic that was tweaked on each shot was the relative layout of the flowers and leaves. Generally, we used flowers to accentuate the lit areas of the plate while the leaves tended to be kept to the shade. Not only did it make sense that a plant would grow that way, but it also helped to get a better sense of depth and shape. It also meant we could keep the orange colors bright and avoid the potential for muddy browns. All of this can be seen to best effect in the “Randy’s Donut” shot in the 60 second version of the spot.

Q. Once the plants and flowers are in place, how does the lighting work so that they look like a natural part of the environment?

A. For many of the shots, we used the Arnold renderer due to the excessive amount of particle instanced geometry we were using. Arnold chews this stuff up and it meant that we could get quite ambitious with the level of detail that we put into some of the shots. For one of the wider city shots at the end of the 60 sec spot we actually used individual flower and leaf instances, despite the fact that you could fit several into a single pixel of the final image. The amount of geometry didn’t seem to matter and in the end it helped to really sell the scale of it all and remain consistent to the other shots with the lighting.

Arnold is also extremely good at bouncing light around in a soft diffuse way. This was perfect for the shot where the man walks out of his house to find it covered in flowers. The final image you see in the spot is pretty close to the render we got straight out of XSI. We just cranked up the bounce lighting component for the shader which helped to soften the lighting and steered it towards the complex light interaction that you get within dense foliage.

For the closeup shots we used mental ray because we know how to get the most out of it to be able to really sell the level of detail that was needed. If you look closely you should be able to see a subtle hair system that was added to the vines for increased realism. Mental ray also has the advantage that it’s The Mill’s primary renderer, so all of our artists know it very well.

Q. When it comes to including the hand animated flowers in the foreground,is this an artistic type of decision – that is, does the simulation hold up only at certain distances from the camera?

A. For me, I think the opening shots of the commercial go to prove that you can’t beat an animator’s sense of timing and composition. Those shots work really well and the level of control the animators have is way above what I can offer as an FX TD writing a simulation.

We did find that from initial tests, the simulation was able to stand up to fairly close scrutiny due to the visual complexity of the stalks and leaves. For the New Orleans balcony shot we used a hand animated rig in the immediate foreground but we were able to use the particle simulation for the rest of the layout. It’s also one of the few shots where we can see the flowers and leaves growing using the particle system.

Q. Are your hand-animated flowers all CG elements or could you employ some live action footage of real flowers?

A. I think it was felt that timelapse footage has the potential to look quite flickery unless done in a very controlled environment, so all the flowers and ivy were done in CG. If we’d gone the timelapse route, I think it would have been tricky to capture all the elements at the correct angles and lighting that we’d have needed.

Q. Are the animators working with the same elements that the simulation is using to populate the environments?

A. No, the assets were quite separate. We had a custom rig for the animation team to be able to grow vines and sprout leaves, and we always had them animating the high resolution flowers. We could blend them in quite easily with the particle based flowers in the distance if necessary.

Q. This application could really be useful in many situations. What ways have you been considering that you could extend or modify it to work for other projects?

A. The first step would be looking into simplification of the simulation. We used three independent particle systems for the vines, stalks, and leaves/flowers and it proved to be a little cumbersome for caching. We occasionally ran into synchronisation issues where leaves would start sprouting in mid air!

After that, it’s all about adding controllability and stability to the system for artists who maybe haven’t quite got into ICE yet but might need to use similar functionality in their projects. Adding convincing vegetation is one of those things that CG generally finds to be quite a difficult challenge, so having a stock solution like this is always useful.

Credits

Agency
Agency: BBDO
Producer: Jenny Russo Novak
Creative Director: Bobby Pierce, Jean Robaire, Stephen McMennamy

Production
Production Company: Rabbit Content
Director: TWiN
Executive Producer: Jeff Sommar, Joby Barnhart
Producer: Zac Zimmerman

Editorial
Editing Company: Arcade Edit
Editor: Paul Martinez
Edit Assist: Will Hasell

Post-Production / VFX
Post-Production / VFX Company: Mill New York
Mill Office: New York
VFX Producer: Boo Wong
Shoot Supervisor: Angus Kneale, Michael Gibson, Adrian Hurley
2D Lead Artists: Westley Sarokin
3D Lead Artists: Rob Petrie, Andy Nicholas
2D Artists: Markus Lundqvist
3D Artists: Andrew Proctor, Vince Baertson, Eva Kuehlmann, Jeff Dates, Boris Ustaev, Ajit Menon, Sam Crees, Naotaka Minami, Hassan Taimur, James Williams
Assist: Brendan O’Neil, Brian Houlihan
Colourist: Fergus McCall
Additional: Nuke: Antoine Douadi, Francois Turquety, Dexter Davey

Last November I took a break in Dahab, Egypt. It’s a great place to windsurf, mainly because it’s a damn sight warmer than over here in the UK, but it also has a large lagoon which protects the main bay from any swell and stops you getting swept out to sea (kinda handy!).

I was over there two years before and managed to get some great shots with my old Canon 300D of some of the pro’s doing various tricks like the “Grubby” pictured below (This is what it should look like).

A word of warning for anyone doing much travelling at the moment. It seems that some of the airlines leaving the UK are getting quite strict about carry-on baggage weight. I’m a bit of a gadget freak, and I don’t particularly trust the baggage handling system, so my carry-on bag had a Macbook Pro, iPad, Canon 5D MkII (with two lenses) and the GoPro HD camera. The check-in girl took one look at the straining shoulder strap and weighed it in at about 13 kilos which is over half the weight of the hold luggage limit! So yes, they made me repack. You have been warned!

So before I went away I bought a GoPro HD. A friend of mine at The Mill had used one on his skiing holiday and it looked pretty awesome. I also saw this great video by GoPro themselves here which is well worth a watch.

They’re not particularly cheap (£269 for the basic set), so I guess it’s understandable that I was a little protective over it the first time I took it out on the water. I had a bit of blast around on the windsurfer, took a look at it and noticed that it wasn’t switched on anymore. I could see that there was water condensation inside the casing too, at which point I assumed the worst and figured that the case had leaked water and shorted out the camera.

Anyway, it turned out that the camera was fine. Apparently, the one issue with the GoPro is that the water tight casing means that changes in temperature can cause condensation to form. The camera had just turned itself off after it had reached the 3.4Gb file size limit and stopped recording (more on this below). GoPro sell anti-fog strips that you can buy that stop fogging from happening, but don’t bother, there are some simple steps you can take that will guarantee you won’t get any fogging and it won’t cost you a penny.

Right, so in the time honoured tradition of internet blogging; here are 10 tips and tricks for making the GoPro work for you:

1. Preventing Condensation

   Condensation is formed when warm humid air meets a cold surface. In my situation, I shut the camera case when it was on dry land in the warm humid air and as soon as the camera got wet, the clear perspex case cooled and condensation formed, resulting in a blurred washed out image. Not nice!

   As I mentioned above, you can use the GoPro anti-fog strips, but otherwise you just need a source of dry cool air. An air-conditioning unit is perfect for this, or a fridge. Whatever you use, expose the case to the cool air for a minute, put the camera inside, and carefully shut the case. As an added precaution, put a small piece of toilet tissue behind the camera. That should make sure you won’t get any condensation at all. Doing this everyday before I went out worked perfectly. (Thanks to the GoPro forums for this tip)

2. Closing the case

   The case is what keeps your £270 camera from annihilation by salty water so it pays to look after the mechanism that keeps it shut. The clip that holds the case shut is made of pretty sturdy stuff. However, it’s plastic, so it’s vulnerable to UV damage from the sun that can cause it to become brittle. Knowing how to shut the case in a way that applies a minimum stress on the clip is a good idea.

   One of the users on the GoPro forums shows the proper way to do it:

   
   

   Another thing to check is the casing’s rubber seal. It’s is the last defence against water getting into the case so you need to treat it with care. It’s always worth just giving it a wipe after being on the beach to make sure you don’t get any sand in it. Hairs getting trapped are another thing to watch out for.

3. Tether it because it doesn’t float!

   You might be surprised to know that no component of the camera system or mounting brackets float. That’s right. It all sinks. Like a stone.

   That’s why it’s essential to tether your camera in some way to something that does float, whether that’s you, your windsurfer, or your rig. This is especially important if you ever wear the camera on your head using the head strap mount. If you get catapulted, you can expect to see your camera bouncing across the water Barnes Wallis style if you don’t have it fixed to you in some way. Generally, you need to keep the tether short so you don’t get strangled, but enough to give it some play.

4. Tighten the screws as much as you can

   The black plastic clamps that fix the camera to the windsurfer mast or boom can flex by quite a lot, but it’s surprisingly tough. You may be scared to tighten the screws too much as it can look as if you’re going to break the clamp, but it’s actually fine. If you don’t tighten it properly, the flexibility can mean that the camera can slip during filming.

   If you watch my video at the bottom of this article, you’ll notice I hit a bit of chop at 1:01 that causes the camera to nod down a few degrees because I didn’t tighten it fully. Oops.

5. Know your hardware limits

   I bought my GoPro with a 16Gb memory card. That’s enough space for about 2 hours of HD footage. As I mentioned above, there’s a 3.4Gb limit on the file size that can be written to the cards (something which is apparently to be fixed by GoPro), so that means a maximum of approximately 30 minutes of continuous video.

   It’s easy to let the camera just run, but unless you keep track of how long it’s been recording, then you run the risk of the camera stopping on you and missing some awesome shots. Unfortunately I learnt this from bitter experience!

   Before every trip out on the windsurfer, I’d start the camera. As soon as I got back, I’d stop it again. Each session lasted on average about 10 minutes so it made sure I always captured the action.

6. Short takes for easy editing

   As a result of the previous point; keeping your takes short makes life a lot easier in post when it comes to editing it all together. Instead of having to trawl through a huge 3.4Gb video file, you can do a lot of culling of unwanted footage by just deleting files.

7. Keeping file size down

   There’s another reason to not let your GoPro camera record for the maximum duration. The longer it records for, the greater the chance exists of a file getting corrupted as it can occasionally write bad data to the movie file. This only happened to me once in a weeks worth of recording and it’s hardly unexpected considering the extreme conditions and motion the camera gets exposed to.

   It’s not a complete disaster though, as it is possible to recover most of the corrupted footage (see below).

8. Firmware upgrade

   When you get your camera, check to see if it has PAL support. If not, go to here and download the latest update. There are a few other additions to the software, but the PAL support is probably the most useful.

9. Recovering corrupt videos

   As mentioned above, the GoPro can occasionally corrupt videos. The good news is that there’s a Perl script that can fix it for you. You can download the original script from this forum post.

   One thing to note is that the script doesn’t directly support the PAL formats, However it’s a fairly simple fix to change the script yourself. You just need to change the $framerate variables at the top from 30 to 25, and from 60 to 50 and it works. (If you can’t figure it out, drop a comment below and I’ll go into more detail).

   If you do this, you’ll find that you should be able to play the file in VLC, but other programs might still have issues opening the video. This may or may not be a problem depending what you’re wanting to do with it.

   Oh, and you’ll also lose audio, but that’s not generally a problem since capturing audio through the waterproof casing is something you’ll rarely want to do anyway.

10. Resolution and implications

    I initially started shooting with full 1920×1080 HD, but ended up switching to 1280×960. Why? Three reasons.

    • Firstly it let me reduce the file size, so I could shoot more footage and have less issues with corruption.
    • Secondly, the full HD refused to load into After Effects whereas the 960p could be loaded directly. I believe you can convert the 1080p using Mpeg Streamclip into a format that After Effects will load, but I’ve not tried it yet.
    • Finally, the format you use results in a different field of view being captured. Footage shot at 1280×960 has a field of view of 170º compared to that at full 1920×1080 HD which has a 25% narrower field of view at 127º. I felt that the wider angle worked better for the shot from the mast so I went with the 960p. Here’s a link to the PDF of the manual. It shows the full range of resolutions that the camera supports.

    From tests I did at 960p, it could be resized up to full 1080p and sharpened slightly to give a very similar result. I need to do a few more experiments with this though, so I’ll post the results up here when I do.

So, here’s the video. You’ll notice that it isn’t as sharp as the GoPro skiing video. I expect that that’s partly down to the fact that I used 960p, but it’s also because I rotated (and therefore cropped) the image to make the camera angle a little more natural.

Thanks again go to the users at the GoPro forum. There’s a wealth of information over there, so go check it out.

Anyway, enjoy…

The Replace ICE String tool lets you effortlessly change attribute names in your ICE trees. This is often a common yet error prone task when tidying up compounds for release, due to long forgotten attributes hidden in the depths of other compounds.

Installation

The plugin is provided as a python plug-in file, and you just need to put it inside a Plugins directory for XSI to recognise it.

Replace ICE String V1.0 (3Kb)

Versions

1.0: Initial release

Getting Started

After you’ve installed the plugin, open an ICE Tree Editor. You should have a new entry in the ICE Tree Editor’s User Tools menu.

Make sure you’ve got an active ICE Tree displayed in the window, and select User Tools -> Replace ICE String. You should see this dialog:

The functionality of this tool shouldn’t need much explanation as it works in the same way as any text based search replace tool. However, there are a few key points that need to be mentioned.

Previews

There is a preview button that shows every replacement the tool will make. It’s always a good idea to do a preview before you run the tool, as it’s easy to overlook situations you might not have considered.

Scope of Replacement

It’s important to note that the search/replace is recursive. It will always drill down into all compounds beneath the inital viewing location in the tree.

When you launch the tool from the menu, it stores the current location of the ICE Tree Editor in the entry called “Ice Tree” (at the top of the dialog). This is where the tool will perform the search and replace. This means that if you view the root of the ICE Tree and run the tool, it will operate on the entire tree. If you are inside a compound, it will only run on the nodes contained in that compound.

If you view a different tree or use another ICE Tree editor, the Replace ICE String tool will not recognise you’ve changed what you’re looking at and will still operate on the original selection, so be careful! To change the location, just open a new Replace ICE String tool dialog from the ICE Tree Editor.

Limiting to Get/Set Data nodes

Generally you only want to replace strings that are located inside Get Data and Set Data nodes, so you have a checkbox that gives you the option to restrict the operation to those nodes to help speed up the process. This filter also includes the Get Data At Previous Frame node.

If you don’t use the Get/Set Data filter, then the tool will attempt to do a search and replace on all string based parameters in your tree. Again, it’s advisable to run a preview before doing this.

Importing Python Modules

Python modules offer a great way to reuse code. Often you’ll find that you want to share code between your plugins, especially in a pipeline situation.

XSI isn’t particularly flexible with how it lets you import modules. At the moment, you have to install your custom written modules in a folder and use the PYTHONPATH environment variable to point to that location (or add it to the list of paths stored in sys.path at run time.)

Wouldn’t it be good if we were able to import Python modules so that:

• You can keep your modules with the plugin that uses them.
• You never have to modify your Python path, even when you move the installed plugin to a different location.
• The module is only loaded when you need it.

Of course, you can just use a standard XSI plugin and register some commands, but there are situations where it might be preferable to use a module. For example:

1. If the functions to be included are very small helper functions that need to be called repeatedly. It might be best to avoid registering commands since they have a slight performance overhead to their execution.
2. If the functions are non XSI specific and don’t make much logical sense to be added as XSI commands.
3. If the functions need to be pass or return Python types such as classes, tuples, sets, lists and dictionaries. There are workarounds for these, but they don’t really assist with making your code clean and maintainable.
4. If you want to keep your code hidden, you can put your implementation inside the module and only distribute the .pyc compiled version.

A new way to import modules

The good news is that you can use the following Python class to mimic the behaviour of an imported module.

import win32com.client
from win32com.client import constants

import os.path
import imp

#Note: You only need the following line if you're
#putting this code in a file that isn't an XSI plugin.
Application = win32com.client.Dispatch("XSI.Application").Application

class Import:

    def __init__(self, pluginName, moduleName):
        self.pluginName = pluginName
        self.moduleName = moduleName
        self.module = None

    def __getattr__(self, name):
        #Has the module already been loaded?
        if self.module:
            return self.module.__dict__[name]

        #Try and load the module
        path=""
        try:
            path = Application.Plugins(self.pluginName).FileName
        except:
            Application.LogMessage("[Plugin Python Module: " \
                             +self.pluginName+"] " \
                             +"Plugin name doesn't exist or hasn't been loaded" \
                             ,constants.siError)
            return None

        #Import the module
        result = imp.find_module(self.moduleName, [os.path.dirname(path)])
        self.module = imp.load_module(self.moduleName, result[0], \
                                      result[1],result[2])

        if not self.module:
            Application.LogMessage("[Plugin Python Module: " \
                             +self.pluginName+"] " \
                             +"Couldn't load module: "+self.moduleName \
                             ,constants.siError)
            return None

        #Evaluate the attribute
        return self.module.__dict__[name]

Assuming you’ve placed the above code into a globally accessible module called xsiimport, then you would use it like this:

Note: I’ve highlighted the specific bits of the code that are relevant

import win32com.client
from win32com.client import constants

import xsiimport

g_PluginName = "TestCommandPlugin"

#Think of this next line as a normal import statement
testpymodule = xsiimport.Import(g_PluginName, "testpymodule")

def XSILoadPlugin( in_reg ):
    in_reg.Author = "Andy"
    in_reg.Name = g_PluginName
    in_reg.Major = 1
    in_reg.Minor = 0

    in_reg.RegisterCommand("MyCommand","MyCommand")
    #RegistrationInsertionPoint - do not remove this line

    return true

def MyCommand_Execute():
    #Use testpymodule as you would any other python module

    #Call functions
    result = testpymodule.DoSomething("inputString")

    #Create classes
    myClassInst = testpymodule.MyClass()

As shown, the easiest way to use this class is to import it from a module located in your standard Python path. As a result this would generally only work in a studio environment where you are able to make sure your art team are working on the same file system and with the same environment variables.

If you intend to distribute your plugin, then the alternative is to copy the class definition to each of your plugins that needs to use it. While untidy, the benefits it offers are probably worth it, but I’ll leave it to you to decide.

How it works

So if you’re interested in what’s happening under the hood, I’ll briefly run through what’s happening.

This line in our plugin:

testpymodule = xsiimport.Import(g_PluginName, "testpymodule")

doesn’t actually do anything apart from create an instance of the Import class. In its constructor, it just stores the name of the plugin and the name of the module we want to import.

The reason the class doesn’t load the module at this stage is because the plugin probably hasn’t been registered with XSI yet (don’t forget, we’re still running code in global scope here). Therefore, we can’t ask XSI for the file path of the plugin using the Application.Plugins collection.

The module only gets loaded when we ask it to do something in our command like this:

    #Call functions
    result = testpymodule.DoSomething("inputString")

    #Create classes
    myClassInst = testpymodule.MyClass()

At this point, the __getattr__ member function of the Import class is called. It checks to see if the module has already been loaded and loads it if it hasn’t. Either way, the class returns the attribute that is asked for, where it is either called as a function or used to create an instance of a class (as shown above).

This delayed loading mechanism is the reason that this system works and why it’s so robust. All other methods that I’ve tried suffer because the plugin isn’t loaded, which forces you to import modules inside function declarations (which feels a bit hacky)

To load the module, I’m using the imp module. It exposes the lower level commands inside the import mechanism. By calling imp.find_module() followed by imp.load_module(), it forces a reload of the module and flushes any cache stored for that module. Generally, this behaviour is desirable as XSI tends to be quite aggressive with it’s caching.

And in case you’re wondering. Yes. This method for importing works fine with the callback mechanism in the previous article.

Update: 25 Oct, 2010

Autodesk’s new release of the XSI 2011 Advantage Pack contains a new python module called siutils that gives you some of the functionality described in this article. Read more here.

The ability to use the __sipath__ variable now means that you don’t need to use the plugin path lookup to find the location of the current plugin. Assuming this value is valid before the plugin is registered (I’ve not tested it yet) then this would remove the need to use the delayed load method discussed in this article.

How to pass functions to PPG logic in Python

When making user interfaces in XSI, I find that I often need to create custom properties on the fly, rather that fully self-installed custom property plugins. When doing this, I usually need to pass callback functions to the PPGLogic attribute so that XSI knows what to do when a button is clicked or a value changes. In JScript, this is simply done using the toString() method of the JScript function object, like this:

function MyJScriptCommand_Execute(  )
{
    prop = XSIFactory.CreateObject("CustomProperty")
    prop.AddParameter2("myValue",siInt4,0,0,100,0,100,
                            siClassifUnknown,
                            siPersistable | siKeyable);

    layout = prop.PPGLayout;
    layout.AddItem("myValue");
    layout.AddButton("myButton");

    layout.language="JScript"
    layout.logic=myValue_OnChanged.toString()+
                     myButton_OnClicked.toString();
    InspectObj(prop);
    return true;
}

function myValue_OnChanged()
{
    LogMessage("myValue was changed");
}

function myButton_OnClicked()
{
    LogMessage("myButton was clicked");
}

Despite the flexibility that Python offers as a language, it doesn’t have a mechanism able to do this. So we need to find another method.

Triple Quoted Strings

One common way to do it is to write your functions inside a triple quoted string. Here’s the Python equivalent of the above code:

def MyPythonCommand_Execute(  ):

    prop = XSIFactory.CreateObject("CustomProperty")
    prop.AddParameter2("myValue",constants.siInt4,0,0,100,0,100,
                            constants.siClassifUnknown,
                            constants.siPersistable | constants.siKeyable)

    layout = prop.PPGLayout
    layout.AddItem("myValue")
    layout.AddButton("myButton")

    layout.Language="Python"
    layout.logic='''
def myValue_OnChanged():
    LogMessage("myValue was changed")

def myButton_OnClicked():
    LogMessage("myButton was clicked")
'''
    Application.InspectObj(prop)
    return true;

This is perfectly acceptable and works fine, but it does have a few drawbacks:

• It makes the code look ugly and less readable. Python is formatted in a specific way due to the indentation being linked to the syntactical interpretation. Putting code inside a triple quoted string goes somewhat against this ideal.
• Most text editors will not show the syntax highlighting for the callback code, and will highlight it as a string. This is a minor problem but can be annoying, particularly if you’re building a complex string with escaped characters.
• All the code inside the triple quotes is executed in a new scope. This means that any global constants, helper functions, or module imports will have to be repeated inside the triple quoted section. This can lead to a lot of code duplication, which is obviously a bad thing.

Using the Logic File attribute

It would be fair to say that the triple quoted string method isn’t particularly convenient. Are there any other ways that we can do this?

Yes. If you look at the PPGLayout attributes, you’ll see that we have the ability to specify a PPG logic file. This is a file in which we can put all our callback functions, and as long as we tell XSI where to find it, everything should work fine. For example:

def MyPythonCommand_Execute(  ):

    prop = XSIFactory.CreateObject("CustomProperty")
    prop.AddParameter2("myValue",constants.siInt4,0,0,100,0,100,
                            constants.siClassifUnknown,
                            constants.siPersistable | constants.siKeyable)

    layout = prop.PPGLayout
    layout.AddItem("myValue")
    layout.AddButton("myButton")

    layout.Language="Python"
    layout.SetAttribute(constants.siUILogicFile,
                        "C:\\Workgroup\\Application\\Plugins\\PPGCallbacks.py")
    Application.InspectObj(prop)

…and in a separate file called PPGCallbacks.py

def myValue_OnChanged():
    LogMessage("myValue was changed")

def myButton_OnClicked():
    LogMessage("myButton was clicked")

This certainly gets around the problem of syntax highlighting, but it still means we have to redeclare global constants, helper functions, and reimport modules. It also gives us two extra problems of having to hardcode the location of the logic file, and having to make sure that the plugin file and the callback file are always installed together. If anything goes wrong with either of those, you’re not going to know about it until you open the PPG and press a button or change a value.

Okay, why not eliminate the extra file and just point it at the original script?

def MyPythonCommand_Execute(  ):

    prop = XSIFactory.CreateObject("CustomProperty")
    prop.AddParameter2("myValue",constants.siInt4,0,0,100,0,100,
                            constants.siClassifUnknown,
                            constants.siPersistable | constants.siKeyable)

    layout = prop.PPGLayout
    layout.AddItem("myValue")
    layout.AddButton("myButton")

    layout.Language="Python"
    layout.SetAttribute(constants.siUILogicFile,
                 "C:\\Workgroup\\Application\\Plugins\\MyPythonPlugin.py")
    Application.InspectObj(prop)

def myValue_OnChanged():
    LogMessage("myValue was changed")

def myButton_OnClicked():
    LogMessage("myButton was clicked")

That’s much better. We don’t need to manage two files and we can put all our callback code in the same file as the PPG definition. It starts behaving a lot like a self-installed custom property, although we still have the problem of hard coding the path.

Using XSI’s plugin registry

The solution is to look up the path to the current plugin file using Application.Plugins.

Let’s look at the details of how this works.

Application.Plugins is a collection of XSI plugin objects. We can retrieve any particular one by asking for it by name. This is the one we declared it with in the registration function.

def XSILoadPlugin( in_reg ):
    in_reg.Author = "Andy"
    in_reg.Name = "My Python Plugin"
    in_reg.Major = 1
    in_reg.Minor = 0

    in_reg.RegisterCommand("MyPythonCommand","MyPythonCommand")
    #RegistrationInsertionPoint - do not remove this line

    return true

By using this name to index into the plugin collection, XSI will return us a Plugin object:

pluginObject = Application.Plugins("My Python Plugin")

Once we have the plugin object we can ask it for its filename:

LogMessage(Application.Plugins("My Python Plugin").FileName)

# INFO : C:\Workgroup\Application\Plugins\MyPythonPlugin.py

So to set the logic file to point to the current plugin, we can just do this:

layout.SetAttribute(constants.siUILogicFile,
                    Application.Plugins("My Python Plugin").FileName)

To obey the rule I mentioned earlier about not defining the same thing twice, we can define the plugin name as a global variable right at the top of the script. The final script looks like this:

import win32com.client
from win32com.client import constants

g_pluginName = "My Python Plugin"

def XSILoadPlugin( in_reg ):
    in_reg.Author = "Andy"
    in_reg.Name = g_pluginName
    in_reg.Major = 1
    in_reg.Minor = 0

    in_reg.RegisterCommand("MyPythonCommand","MyPythonCommand")
    #RegistrationInsertionPoint - do not remove this line

    return true

def MyPythonCommand_Execute(  ):

    prop = XSIFactory.CreateObject("CustomProperty")
    prop.AddParameter2("myValue",constants.siInt4,0,0,100,0,100,
                            constants.siClassifUnknown,
                            constants.siPersistable | constants.siKeyable)

    layout = prop.PPGLayout
    layout.AddItem("myValue")
    layout.AddButton("myButton")

    layout.Language="Python"
    layout.SetAttribute(constants.siUILogicFile,
                        Application.Plugins(g_pluginName).FileName)
    Application.InspectObj(prop)

def myValue_OnChanged():
    LogMessage("myValue was changed")

def myButton_OnClicked():
    LogMessage("myButton was clicked")

That’s all there is to it. Now we have a workable strategy that has the following advantages:

• Tidy code
• Full syntax highlighting
• All the code is in a single file
• All the constant definitions, helper functions, and imports only need to be written once

Note that the callback code is still being executed in a different context. There’s no way around that. This means that changes to the values of global variables will not get passed through to the callback code. Global constants work fine because they are declared in global scope and don’t change.

In the second installment of this article, I’ll be showing you how to load python modules that are specific to your plugin using a similar system.