If the FxTree crashes when you open it, it is because of one of these two causes:

1. the RAM settings are too high
2. you’re running out of disk in the drive where the %TEMP% (or $TMP on unix) variable is pointing to

The important setting is called Image Memory Size (MB). By default, it is 40 megs. In 32-bit, it should never really be higher than 128 megs of ram, because that’s as large as you can safely get in one contiguous block even if you have 3 Gig of RAM. It is the size of one huge memory pool that the FxTree will allocate on startup. In other words, its the minimum amount of RAM to allocate when the FxTree start. In other application, this setting is normally the maximum to allocate! A trivial composite can be assumed to need at least 5 times the amount of RAM of a single image.

In order to be able to resize its memory elegantly (I know, this is ironic), the FxTree allocates a swap file that’s as large as that memory setting. The swap file is located in %TEMP%\XSI_Temp_pid. The hard disk needs to have enough space for it. To quickly go there, at the command line do “CD /D %TEMP%” (/D allows “CD” to change drive if it needs to, otherwise it only changes directory)

In 64-bit you can make the FxTree memory very large, and therefore get a real-time RAM flipbook for free. However, keep watching for space for that swap file on disk. It’ll take a few seconds for the FxTree to allocate that swap file.

If you don’t use the FxTree views and have no FxTree operator in your scene, that memory will never be allocated.

You can right-click on an FxTree node and select “Live Caching”. In this case, the output of the operator will be cached to RAM, for multiple frames, and if the memory runs low it’ll swap to disk using the Disk Usage settings. You would do this for an operator or a branch of the tree that takes a long time to render. It doesn’t persist the setting, but it’s the equivalent of doing a precomp in other products. All file input operators are using ‘live caching’ by default, except with disk swapping disabled, which is why you can sometimes see a yellow diamond (the Live Caching icon) on file input nodes.

Swapping to disk also happens if you use raster paint, or press Play in the FxViewer and it runs out of RAM. Otherwise, these disk options are not used and I’ve never really seen any user having problems with them.

There are three main new items in the Fx Tree for version 6.0.

The first one is the integration of the warp kernel from Elastic Reality, as a new “morpher” and “warper” transform effect.

The second one is a new image compare feature in the Fx Viewer which is more like the one Shake. The existing image compare function is still there, but it is more useful to compare changes while editing an image, while the new one is more useful when comparing two full screen image sequences.

The third one is basic OpenEXR 16-bit float native support and requires a bit of explanation.

First, the XSI FX Tree is Windows port of Avid Media Illusion, which had very limited floating point support. It supported the 32-bit float images, but only to gain extra precision and not to process color values that are outside of the 0.0 and 1.0 range. That sounds silly nowadays, but most Media Illusion users at the time (1996) would be working in 16-bit, with cineon files, and wouldn’t immediately use this, so there would have been time to gradually add support for HDR when it became relevant. Illusion also had video support, which definitely did not support HDR imaging, and that uses 8-bit YUV storage in order to be real-time. In other words, floating point images wasn’t a feature that was in use, and therefore it wasn’t really implemented when the development of the product ended.

One additional problem with 32-bit float images is that they are slower to process, and take four times as much RAM. The RAM part is an especially critical issue. Floating point is so tempting to use, there is no doubt that if it were enabled in the Fx Tree people would use it and then run into huge memory allocation issues. It’s not that much of a problem in Shake because it is a tile-based architecture, but Illusion is not made this way, it needs to hold complete images in RAM.

During some down time after Siggraph 2006 in Boston, I began implementing part one of my plan to move the Fx Tree forward, and this is what you get in XSI 6.0

The first thing is to focus on ILM’s 16-bit float image format. This format trades some runtime performance to get lower memory consumption. The image format is also directly supported by the GPUs.

The images in RAM are the same size as “normal” 16-bit images, which I will refer to as “16-bit unsigned short images”, and we know the Fx Tree can handle those very well. And just like any 16-bit image format, it is possible to do very fast look-up-table processing with them.

Look up table operations on 32-bit float images are not directly possible, and doing the equivalent require a lot more processing, or using the GPU. Look up tables on 8 and 16-bit images requires only a few CPU instructions and a 256 byte and 65535*2 bytes LUT.

Finally, it is generally accepted that the 16-bit float OpenEXR image format is “good enough” for most images. Meaning, it does trade some precision, and the range is not infinite like 32-bit float, but it is very good. For example, between 0.0 and 1.0, there is still more precision in a normal 16-bit unsigned image, where there are 65535 discreet values instead of 15361 like 16-bit float, but generally the human cannot see them, and preserving the values that are out of that range is more important to the quality of the image processing.

So in the FxTree the first thing I did was introduce a new image format I called “HDR”, which is 16-bit floating point. It was named this way, and put after the existing “float” in order to make it obviously that this is where the effort is focused for HDR support (i.e. high dynamic range pixel values), and that it is better.

Then, the core tools were updated, in order of importance for compositing passes, until time ran out on 6.0.

“Supporting HDR” means that an effect supports processing the 16-bit float image without clamping the values. Many of the 32-bit float code path were updated, but generally it should be assumed that there were not and you shouldn’t use them. The HDR code path are always going to execute much faster because the code is new, optimized and painstakingly verified.

The 6.0 Fx Tree now loads OpenEXR images as “HDR” 16-bit float images, and can save them back to disk without loss of data, so File Input and File Output both support HDR. All effects in the “filters” group, plus Over, Transform, crop, Math Composite, support HDR.

However, it stops there. The PainterlyFx, which are an 8-bit photoshop plug-in library, do not support HDR. Keyer, Paint, Warper, Morph, shapes, Distort and none of the color correction tools support HDR or float without clamping, except for the HSV Adjust effect in RGB mode.

To color correct HDR images, you’ll need to use the HSV Adjust’s RGB controls, which are in the “Basic” and “RGB Graph” group. The Fx Viewer uses it internally to apply display LUT. Anything that uses HSV or HLS will clamp the HDR values.

So as you can see, it’s partial support. It’ll get you up and running for doing simple compositing and blurs of mental ray passes. I expect that in the future more effects will support HDR, but I can’t promise a roadmap for this at this time. I think it’s worth putting this in the hands of users even if it isn’t completed. Ideally I’d like in the future to drop the support for non-HDR image formats in order to cut down on the development time, testing, of each code path.

The new image format has also been added to the UFO SDK, users simply need to use the “half” c++ class in the OpenEXR SDK to process the pixels.

In this article I will show how it is possible in Softimage XSI to interactively paint the lighting with the FXtree.

A bit of background

In Mental Ray there are two ways to use image-based lighting. The first one is to turn on Final gathering and use an environment shader. The second way is to use an occlusion shader in Sampled Environment mode. You will find all the information to use this shader here (pdf).

I choose to use the second method for this article as the painting technique creates a “low dynamic range image”. It will be easier to paint such an image and have good tonemapping between bright color and dark color than it would be with a high dynamic range image that is more optimal for final gathering. Also for static objects you can render map the occlusion and the render time will be faster. It is possible to render map only the self occlusion to be able to move the non-deformable objects but as far as I know it is only implemented standalone Mental Ray and not yet exposed in XSI. You will find information in this article by Harry Bardak.

Setting the environment up

Assuming you already know how to setup the occlusion shader, I will focus on the painting process.

How to know were does the light comes from?

As the map will be used by the environment shader, it will, by default, be wrapped on an infinite sphere around the scene. We will paint in a 2D UV space. To precisely paint our “lights” on the map we need to know where we are. Use the picture below as an environment map and set the “Spread” parameter to 0 in your occlusion shader to find your way.

The Black to white gradient is the seam where the left and the right stick together. It is aligned with the Z axis. If we need a light with a position equal to 0 on the Z axis we must paint half a light on each side of the seam. In the video capture at the end of this article I will show how to deal with this particular position with a bunch of FXtree nodes. The other way is to rotate the spherical projection on the Y axis in the environment shader to avoid a sun light in the side of the map.

You will see the non blured picture like bellow.

Painting the map in the FXtree:

Now than we know where are the front, back, left and right we can start painting!

By default the map used in your environment shader is the noIcon pic, you can get it in the FXtree from the clip menu. Then add a vector paint node and set its size to 128 by 64 pixels. The smaller the environment map is, the faster the render will be. Plug the vector node in the “ToClip_noIcon_pic” input. Now you can start to paint the sky for example. Keep a render region and an FX viewer open at the same time to see how your painted lights behave on the 3D objects.

Now all you need is to add one vector paint node by shape . You could use only one vector paint but in this case you couldn’t change the order of the shapes. The interesting thing is that you will often use large white ellipsoid shape and it won’t be longer to render when compared to area lights.

You can add as many nodes as you need, it won”t change the render time.

You will find a video capture showing the process here. You will need the TechSmith codec for this one.

I hope you found this article interesting. Happy PBL :-)

The tricks bellow work with all mask shapes, and the “Shape Paste” and “Shape Cutter” Fx Tree operators in the “Composite” group , but they do not work with “Vector Paint” or the “Mask Shape” operator (in the “Image” group).

First, if you select a mask shape in the Fx Viewer, and pop a floating Animation Editor, you”ll find all the FCurves for all the points of the shapes.

You can also open the Animation Editor from the by right-clicking on the Auto button at the top left of the property page. This totally hidden menu will open the Animation Editor scoped on the inspected objects.

Once you”re in the Animation Editor, you could switch on a mini-dopesheet mode by turning on View|Meta Curve Region.

Actually, ignore that and switch to the Dopesheet, and turn off Edit|Align Track View Tree View.

Fx Tree And Selection

Now you can tell that there is something funky going on with selection and the Fx Tree. Here’’s what you need to know.

If you select shapes in the Fx Viewer, the are selected “for real” in XSI’’s selection list (which allows you, for example, to press [enter] to get their property pages) and the Animation Editor (“AE”) or Dopesheet (“DS”) will recycle if you forget to lock it.

If you press the Edit icon (“E”) on an Fx Tree operator, it will select it in XSI’’s selection list.

To get your AE/DS scoped on all the shapes you”re working on, click E on the Fx Operator to refresh the selection, then lock AE/DS. Then you can get to work without having the dopesheet refreshing when you select a new shape.

The Property Page for Fx Tree Operators is not recyling when you select shapes in the FxViewer, because when it’’s opened by the “E” icon, it’’s set to the ever-obscure “Follow” mode. The icon on the title bar that looks like Kenny from South Park… The behaviour of this is to recycle only if the selection changes to an object of the same “Family”, and Shapes are in a different Family than Fx Tree Operators.

Naturally, we”ll be working on improving this area in the future.

And now for the 10,000$ question.. How Can I copy shapes to another Fx Operator?

If you are going to be using the same shapes in multiple Fx Tree Operators. you should be doing them in a separate Shape Paste Operator and connect the output of that into the Obey Matte input (the blue icon) all operators where you will need them.

This will of course allow you to do the job only once! And the performance will be better, because the result will be cached. Since you can easily manipulate shapes in the Shape Paste node while viewing the output of another node, there is no reason to not do this.. however some people persist in wanting to copy shapes between Operators.

To view and edit different nodes, click on the Edit (“E”) icon on one node to get its tools in the Fx Viewer, then click “V” on the node you want to see the output of. This allows you to edit the shapes in one node, and view what it’’s going to look like down the tree.

But what if you”re really, really want to copy this shape list to another node? You”re going to have to resort to an obscure scripting hack and use the quirky SavePreset script commands.

Here is a script that will create an ”over” node with a couple of shapes, and copy these shapes to a Tint node. The two final lines is the magic, simply replace FxTree.Over and FxTree.Tint with the names of the Source and Destination nodes in your Fx Tree.

NewScene
CreateFxTree
AddFxOp "FxTree", "Over"
Add2DShape "FxTree.Over.sl.GarbageShapes", "Polygon"
Move2DShapePin "FxTree.Over.sl.GarbageShapes.Polygon", 108.5, 221.75
Add2DShapePoint "FxTree.Over.sl.GarbageShapes.Polygon", 63, 273
Add2DShapePoint "FxTree.Over.sl.GarbageShapes.Polygon", 59, 209
Add2DShapePoint "FxTree.Over.sl.GarbageShapes.Polygon", 142, 173
Add2DShapePoint "FxTree.Over.sl.GarbageShapes.Polygon", 170, 232
Add2DShape "FxTree.Over.sl.GarbageShapes", "Bezier"
Move2DShapePin "FxTree.Over.sl.GarbageShapes.Bezier", 337.2, 168.133333333333
Add2DShapePointArray "FxTree.Over.sl.GarbageShapes.Bezier", Array(275, 226, 236, 134, 345, 58, 457, 162, 373, 260)
Move2DShapeRHandle "FxTree.Over.sl.GarbageShapes.Bezier", 1, , -1
Move2DShapeRHandle "FxTree.Over.sl.GarbageShapes.Bezier", 2, 3
Move2DShapeRHandle "FxTree.Over.sl.GarbageShapes.Bezier", 3, , 3
Move2DShapeRHandle "FxTree.Over.sl.GarbageShapes.Bezier", 4, -3
Move2DShapeLHandle "FxTree.Over.sl.GarbageShapes.Bezier", , 38, 55
Move2DShapeRHandle "FxTree.Over.sl.GarbageShapes.Bezier", , -38, -55
AddFxOp "FxTree", "Tint"
SetFxOpPos "FxTree.Tint", 409, 133

SavePreset "FxTree.Over.sl.GarbageShapes", "MyTempShapeList",
SILoadPreset "MyTempShapeList", "FxTree.Tint.sl.GarbageShapes"

It needs a little bit of testing, and works with either XSI 4.2 or XSI 5.0.

To Install :

1. Download PsdBlendBeta.xsiaddon to your hard disk (compiled for Windows only)
2. Install it, for example by using the AddOn->Install menu in the File Menu.
3. Restart XSI

Usage :
The plug-in can be found in the Plugins group, probably named “Plugins[U]” (to indicate it’’s in the User location). Connect two images to it. Click and drag in the viewer to set the foreground image offset, or middle-click drag to pan the background. You should be able to post here any problem you encounter with it.

p.s. : Cool people add fxtree operators by clicking them in the Operator Selector, and then middle-clicking several times in the fxtree to chose the 1) first input 2) second input 3) output (if necessary) and finnally middle click in the background to set the insert location. The Fx operator selector shows which connection is currently being selected. Select any optionnal inputs you want to pick by first clicking the checkbox next to it in the Operator Selector

There is also a thread on XSI base
http://www.xsibase.com/forum/index.php?board=12;action=display;threadid=21565