Recent Posts

As I’m sure you know, XSI (and almost all 3D/graphics programs) mix colour in an addative RGB(A) manner. This is reasonably obvious and straight forward for most of the time, but when I was playing around with the Add Colour nodes I’ve blogged about previously I happened on something slightly off:

The idea of this test was that each of the spheres would add blue and red respectively, then the slab at the top of the screen would add yellow. There’s no problems there with the red blending through orange to yellow, but try as I might I couldn’t get it to blend ‘blue – green – yellow’ correctly. As every colour wheel will tell you, this is the way things should be and generally would look a lot better than how it is at the moment.

This is the trouble I sometimes have with RGB – I still revert back to my secondary school art theory of ‘red – yellow – blue’ primary colours. This isn’t necessarily a bad thing, at the end of the day colour theory is the same now as it was then, but it does mean that it pays to double check that you’re not being complacent and/or presumptive.

If we look at the actual numbers we’re playing with we can see our problem: we’re trying to go from blue (which, in RGB, is 0,0,1) to yellow (1,1,0) via green (0,1,0). Thinking about this in raw data for you can see the problem – getting from blue (0,0,1) to red (1,0,0) via purple (0.5,0,0.5) is easy as we’re only changing two out of the three values, but this requires us to first add the green while taking away the blue, then adding in the red.

This video has two tests to demonstrate: the first is blending from blue to yellow using a single Add Colour node. The second uses two overlapping nodes to get a better, more natural blend.

Here’s the colour part of the ICE Tree for the first example:

Simple Blue to Yellow

…and here’s the second:

Complex Blue to Yellow

As you can tell, there’s afair amound of tweeking involved to get the right balance and I’d highly recommend these kinds of isolated tests to find what works – it’s one thing to do it for a very abstract example such as this but these principles can still hold true for more subtle colour shifts. Besides, even if you’re going from blue to red you might want to weight the purple more to blue, meaning that you’d have to employ a similar technique adding a more and more red at closer and closer intervals by multiple Add Colour nodes.

My previous ‘Add Colour on Distance’ node for playing with particle colour had something of a limitation in that it could only be used once in an ICE Tree – trying to use multiple colour inputs just wouldn’t work. This is due to the fact that it uses a ‘Set Particle Colour’ node in the compound, so if you have more than one XSI will change the colour twice on the same frame.

To get around his we want to use a solution which only uses a single ‘Set Particle Colour’ node. The best way of doing this is to change the order in which we do things a little. The idea is to have a number of colours being added together which we then clamp and set. The colour we’re adding together can be calculated by testing the distance of the particle to the surface and, if it’s too far way, adding colour with all it’s values zeroed (resulting in no change). If it’s close enough then we can add a little bit of something more interesting.

To make things a bit neater, I created a compound called ‘Test Distance and Add Colour’, which you’re free to download. Stick it into your user compounds folder and it’ll show up under ‘Tasks/Particles/Colour’. It’s a very simple one, nothing complicated, which just tests the distance of a particle from a surface and has a colour value for both true and false outcomes. The user can define the true value from the node as well as the distance to start adding the colour.

Test Distance and Add Colour node

Test distance and add colourxsicompound (.txt file, change to an .xsicompound to use)

Once you’ve set up the nodes you’ll want to pipe them into an ‘Add Colour’ node, along with a ‘Get Data from Previous Frame’ node looking at ‘Self.Color’ (very important that one!). I’d also recommend using a clamp to stop the values getting too large – this can cause problems if you want to blend colours and can cause havoc when it comes to lighting and rendering. Once we’ve got that all set up we can finally set the colour on the particles.

To demonstrate this in action I’ve made a little example which you can see below, along with the ICE Tree I used. You can see in it that I set up the colours to be created from a single scalar value piped into the appropriate value I wanted to add, then multiplied by -1 for those I wanted to take away. This made it much easier to test and balance out how much I wanted to add and take away. You don’t need to do this – in fact there are some situations where it wouldn’t be helpful (which I’ll post about later), but in this case it was pretty helpful.

ICE Tree for the video above

For this I’ll be using a little bit of vector maths to ’slice’ thorugh the point cloud, deleting any particles heading for the camera, for example to create a disc effect around a spherical emitter.

We can get the direction vector of the camera by subtracting the interest’s global position by it’s own. Nicely there’s actually a node already in ICE called ‘Get particle Movement’ which will give you the direction of each particle on the current frame. Before using these two bits of data we need to normalise them – a 3D vector includes a length as well as a direction, normalising them sets the length to 1, making it easier to compare direction, otherwise the dot product we’ll be doing next will give us some clunky-to-use numbers…

By taking the Dot Product of two normalised vectors we get a value between -1 and 1 which can tell us how close they are to being the same (with -1 being the opposite direction, 0 being perpendicular and 1 being the same direction). So by deleting every particle with a dot product above, say, 0.4 and below -0.4 we can cut the particles emitted from a sphere into a disc:

What I said but in annotated ICE form...

The benefit of doing this is if (for example) you’re emitting points from a sphere whilst modifying the colour – what can happen is that the particles on the outside block the ones at the core, meaning that you can’t see anything underneith.

For more of a visual example, I’ve put together a few quick tests to demonstrate:

Shot Breakdown:

Shot 1: Bog standard emit from sphere. Just colour (using the Add Colour on Distance node from my earlier blog), deleting particles at their age limit and a simple volume shader.

Shot 2: Same as above, but with the CamSlice node attached.

Shot 3: A more complicated ICE Tree set-up (see below)with the sphere moving in space

Shot 4: As above, but with the CamSlice ‘cut factor’ being animated from 1 to 0.2

Shot 5: Again, the more compex ICE Tree, with the camera being animated around the sphere

Shot 6: Same scene as Shot 5, but from a different camera unconnected to the CamSlice node. The camera from Shot 5 is represented by a blue rectangle

The more complex tree

For the full ICE tree I played with the colour by using the Add Colour on Distance node when the particle was young, then dulling it when it got old. There’s a few basic forces thrown in there with just a little bit of turbulance added, plus a little push in the Z axis when they get older. The CamSlice node is being used only when the particles are young, once they’re set in the right direction I’ve left them to drift a little.

If you fancy using  this CamSlice technique, feel free to nab this compound and have a rummage around in there yourself. Just download the file below and change the full name from ‘CamSlicexsicompound.txt’ to ‘CamSlice.xsicompound’ and stick it into your user compounds folder – it’ll show up under ‘Tasks/Particles/Deleting Particles’. Don’t forget that if you only want to delete particles heading towards the camera (to keep the volume behind the emitter) then you just need to disconnect the ‘less than’ if node:

CamSlicexsicompound (text file – change to a .xsicompound to use)

As a follow up to Part 1, I’m now going to run through how to bake out your animation into a Unity-friendly format. The benifit of this particular way of doing it is that the animators will be free to add any extra controls they fancy (such as a direction constraint for the head, for example) in their own scenes – we’re going to be ripping the animation from the _env nulls we created in part 1 rather than the rig so as long as they’re intect we should be fine.

Right, first things first, we need some lovely animation to save out…

...lovely animation.

What we’re going to do now is plot the local transforms of the nulls, save it to an action clip and export that out to use later. This is a tedious task which, as always, can be eased by nabbing someone’s script….

DemonProject_ExportGroup_pub_v02pys (text file, rename it to a .pys to use)

This script will prompt the user to select a group containing all of the _env nulls we want to export (though it could include anything really), which should have been created if you used any of my tools from Part1. It will then plot the local transformations and automatically create and save an action clip to your project root. Do this for each animation sequence and we’ll be good to go.

Now, create a new scene (making sure that the frame-rates and things are set up correctly and are the same as the animation scenes) and import the model everyone has been animating with.

Imported Rig

Now we need to delete all the skeleton objects. This will free the nulls from their constraints and will allow us to add action clips to them.

Deleted Skeleton

..like so! Now we can bring in our action clips and set them up in a row in the Animation Mixer:

Imported Clips

We can’t export this just yet as Unity won’t care about any action clips. We’ll have to apply the actions to the nulls but, because of the way XSI likes to do things, we need to first select them all in the mixer and freeze them into a single new, shiny clip.

Freezing Action Clips

Now we’ve just got the single, all-encompassing action clip we can apply it. If you do this correctly you’ll be able to delete the clip afterwards and the model will still animate correctly. You’ll need to select the frozen clip from the explorer to do this, as shown in the image below…

Applying Frozen Clip

With this done we’re good to go! The last step is just exporting the model out as an .fbx file (the option is found under “File > Crosswalk > Export FBX…”). Strip out all the things we don’t need (i.e. lights, cameras etc) and you’ll have a file that Unity will be able to work with. Just make sure to note down what frames reference what clips and everyone will be (relatively) happy!

FBX Export

As well as being a rather nifty effects-device, ICE also has a lot to offer as a tool for rigging, particularly for those more inclinded to the art side of things. It offers a visual apporach to scripting compared to more traditional operators or expressions. Being able to drag in object and riffle through their available parameters makes for a very organic (if occasionally cluttered) working method.

In this post I’ll be explaining how I made the stretchy arms for my Masters Project rig (see the final thing in action here) using ICE. In theory there’s nothing stopping you from following the same process with an expression but, well, why waste a shiny new tool?!

What we’ll be doing here is creating an ICE Tree for each stretchy bone and setting Data on it’s self.length parameter. For this to all work we’ll need the following ‘ingredients’:

• An IK/FK arm (obviously)
• The length of both arm bones (in this case it’s 5.67)
• The length of the unstretched bone (3.17 for this example)
• A DisplayInfo Custom Parameter on the bone to create the FK stretch (make sure that the default value is 1)
• An IK/FK blend DisplayInfo Custom Parameter on the IK control (a float between 0 and 1)

First we’ll see how to make a basic FK stretch. It’s really, really easy: it just involves multiplying the bone’s length by the Custom Parameter and setting the Data.

Then, to make the IK stretch it’s just a case of getting the distance between the arm’s root and the IK control. If it’s longer than the full length of the arm we’ll need to add a value onto the bone’s length. First we find out just how much more we need to add on by taking the arm’s length off of the distance we need. Then we divide that number by two (as we’ll be giving a bit to each bone to preserve the ratio) and add it onto the original length. We can set the self.length data with that value.

So now we have two values – one for the amount for the FK stretch, one for the IK. The easiest way to blend between the two is to use the IK/FK value (which I presume you have anyway as part of the Arm IK/FK setup). We can one of the stretchy values by this to smoothly turn it on and off (so if we’re adding, say, 2 to the arm’s length we’ll be timesing it by a value between 0 (for off) and 1 (for on)). At the same time we can multiply the other stretchy value by the inverse (to get this simply do a ‘1 – value’ calculation) to provide a smooth blend.

As part of a personal project I’ve got going at the moment I’ve been playing around with particle colours in ICE. The most obvious way of doing this is with the Modify Colour node. It’s pretty easy to link this up with the age percentage to get a nice gradation in hue:

Modify Colour Node

Now this is all well and good, however, when things get more complicated you may end up deleting a lot of particles before they’ve got the chance to become old. In this case you might well want to use another way to grade the colour. In this example I’ve tested the distance from the sphere and, once it’s more than 5 units away, added some colour every frame. You only need to add/remove a little bit to achieve a similar effect to the Modify method, though it’s usually a good idea to clamp the values to ensure that the particles don’t over-saturate.

Distance test to apply colour

We can use pretty much any parameter to test in a similar way. In this example I’ve emitted spheres towards a floor and compared their relative positions in y.  Using this method I can add in the blue when they’re approaching the floor, then mix the green back in when they bounce back up:

ICE Tree

Obviously this is a pretty simple, isolated test, but it’s easy to see how more of these parameter comparissons can be used to layer in more advanced changes.

If you’d like to play around with this techique yourself then feel free to download the following node, just change the file extension and you’ll be able to rummage around for yourself. Stick it into your user compounds folder and it’ll show up under ‘Tasks/Particles/Colour’. The node will test a particle’s position with whatever object you plug in and will add colour after and/or before the desired distance:

Add colour on distancexsicompound (.txt file, change to an .xsicompound to use)

UPDATE: There is a limitation with this node in that it can only be used once in an ICE Tree. See this post for more details and for a new solution! This node will still work for single colour changes – as you can see from this new video:

Recently I’ve been doing some rigging and animation for a games project, where the final assets will need to be exported to the Unity engine.  This means that we won’t be able to give the game engine a straight XSI rig to play with – we’ll need to simplify it a bit first.

What we want to give the engine is a bunch of nulls, all in a single hierarchy, as if it’s a full FK rig.  The nulls make the information easy to transfer (we’ll just need them, the geometry and the envelope data) and keeping them in a FK hierarchy will make for better animation blending in the engine (as a general rule: blending between local rotations = good, blending between translations = bad!).

At the same time, however, we’ll still want to keep all the benefits of an XSI rig – from basic things like IK chains to expressions and ICE Trees. The solution to this is to go ahead and make the best, most advanced, most complicated XSI Rig you fancy…

Witness the complication!

So here you go, one rig I made earlier. Now, instead of enveloping as we would normally, we’re going to want to make a bunch of nulls, Pose constrain them to the appropriate bones or controllers and organise them into a hirarcical FK structure. You’re welcome to do this manually if you really want, I just went ahead and made a script to do most of the work for me…

DemonProject_CreateENVnulls_pub_v01pys (text file, rename it to a .pys to use)

This will do most of the work for you (with a few provisos listed in the opening comments – please read them before you use it). At the moment though I haven’t put in a way to sort and structures built outside of the COG/Hips (such as IK feet) so you’ll have to do that yourself for now. Once this tool has been run then you’ll have something which should go from looking a like this:

Before running the tool

…to something like this:

After running the tool

As you can see, there’s a ton of nulls which have been made rather quickly and plenty of tedious sorting avoided.

HOWEVER! Sometimes when making a reverse foot I end up with bones pointing the ‘wrong’ way down the chain. I’ve included a function in the script which will look for these and compensate the Pose constraint accordingly so that the null’s local translationswill work properly. The way the script finds these bones is by looking and seeing if their effector is constraining another effector (say, if the foot’s effector is constaining a leg effector to create an IK control). If your method is different then you can either adapt the script or run this little tool instead:

DemonProject_CompNulls__pub_v01pys (text file, rename it to a .pys to use)

A reverse foot, without the compensation tool and with

Now it’s just a simple case of tidying up the hirarchy and hiding the envelope nulls group…

Ta-Da!

…and now we can go ahead, envelop the geometry to these nulls and animate on our nice, fancy XSI rig. Later on we’ll be using these nulls to put together the animation clips. But more on that later…

Edit: here, in fact!

Hi, well done for finding my blog, no idea how you managed it but hopefully there’s something of interest around here!  I’m going to be using this little corner of the internet to make notes on my work, keep track of any solutions or tips I find and generally make sure that I don’t forget anything useful.

There’s already quite a number of good guides for 3D and XSI strewn across the internet so I’ll be offering smaller notes based around the niggly little problems I find myself running into. I figure that if I’ve been stuck on these things then there’s a pretty good chance that someone else out there will be at some point as well, hopefully this blog will save both of us some 3D-inspired anxiety!

Peter