Everyone complained (including me) that the old particle system was too weak, too limited…. But it was fast to get some things done. To randomize a value, for example, you simply had to open a property page and set a variance parameter. Partly because ICE is so open, to vary a parameter, you have to search for the desired compound or node modifier, drag & drop, connect ports and then set values in the new compounds. Read me right, ICE is very powerful but if you have to modify dozens of parameters hundreds of times in one typical work day, this work flow becomes redundant an inefficient. There must be a way to be quicker.

Softimage proposed a work flow that can be described as follows: a technical director connects basic nodes, designs compounds and exposes ports. An artist, who is not necessary knowledgeable of ICE, then sets the different values of the exposed parameters. Some problems may arise with this approach. How can a TD predict every alteration needed by the artist? In the context of a particle simulation of falling rain, for example, a TD may have to design his compounds to support, for a simple shot, wind and gravity. Then, another shot may require water splashes from the droplet hitting the ground. Another still, requires the same rain but with the added effect of coagulating droplets on a smooth surface. And so on. You can easily imagine multiple variations of the same effect. So how are TDs supposed to tailor their compounds to fit all of the artists needs? One obvious solution is to build a system of compounds rather than a top level one. Yet the artists would need to be taught and learn how this system works and therefore, learn how to use ICE. Yes, maybe… but unlikely. I know many technical XSI users that were clueless on how create a simple simulation; artists, even less probable. How can technical directors empower artists without limiting them with a simple set of parameters? There should be a window to deliver the power of ICE to artists without being too painful. Artists should be able to easily create simple particle animation. You do not need to be a mechanic to drive a car.

With these observations in mind came the search for a way to simplify the ICE work flow which any Softimage user would understand and produce simulations in no time. The intent is not to replace the current work flow but to complement it and accelerate the multiple iterations needed in order to design particle simulations. Subsequent refinements, complex connections or relationships can and should be achieved the traditional way by connecting nodes and compounds in the ICE tree. But once a new solution is found, it should be easy to re-integrate it in a simpler work flow system. It should also be seen as an added value to cut the time to help generate about 75% of particle animation scenarios.

You do not need to look very far to find solutions. By simply looking at the different ways shaders can be modified, it is easy to wonder why ICE property pages were not designed the same way. Isn’t it faster in many situations to create connections by using the plug icon in a shader’s property page rather than opening it in the render tree, dragging and dropping a node, then making the connection? It should be the same in ICE property pages. No?

Also, all parameters affecting the simulation should reside in the same property page. With a typical ICE tree containing easily 20 compounds or more, finding a parameter often requires a search through many compounds. Too many doubles clicks are required to access the compounds’ parameters; why not put them in one location. When a scalar is randomized for example, the parameters associated with randomization should replace the original scalar in the top property page. You say: isn’t the top compound intended for that? Yes, but it doesn’t expose ports automatically. Remember, the goal here is to create particle simulations in a production environment; not to design ICE trees in a R&D context.

In the following video, I demonstrate a working prototype. It shows the above ideas in action with the exception of having iterations made through parameter contextual menus instead of the plug connection icon menu. The Softimage development kit does not give access to this type of UI widgets for ICE compounds property pages. Also, for clarity’s sake, it would have been beneficial to have used tabs in the property page to seperate emission, particle type, forces, triggers and events. This was not implemented. This prototype was written about a year and a half ago with a beta version of XSI 7.0 and unfortunately has not been updated to work with the current version of Softimage but would be relatively simple to rewrite. I must also credit my colleagues at the time, Jeff Wilson, who helped with the original concept and Javier von der Pahlen who co-wrote the prototype. It is important also to say that I was an employee of Softimage at the time when that prototype was written. As a long time user of Softimage’s products, I was trying to push solutions that made the work of technical directors easier. Unfortunately, this concept was not accepted. But it remains a great concept on how technical directors can go beyond compounds and integrate ICE in production pipelines more efficiently. It clearly illustrate the ability to build a simple particle animation rapidly without having to access the ICE tree. All iterations are made through the property page.

I simply wanted to share these ideas with the Softimage community and start a discussion. As, hopefully, more and more people will be using ICE, I’m sure that work flows will evolve to more efficient ways to manage ICE trees. Maybe it’ll lead to similar solutions, whether it comes from Autodesk or the community. I think it’s really cool concept and it would save many users time and headaches. What do you think? Is this type work flow worth exploring?

PPG Based Particle Animation Work Flow With ICE from Hans Payer on Vimeo.

Since the Histogram display window is just a COM application launched by the equivalent mental ray shader, there’s nothing stopping you using the Histogram display tool for other uses. Indeed, I included in the original download example source scripts to demonstrate how to drive the COM interface.

Vince Fortin has asked me about whether it’s possible to get Histogram to show distributions for particle systems. So at his request (thanks for reminding me Vince!) I’m posting some example code to show you how to do it.

First though, here’s a quick screen shot of the sort of information it can show:

Here I’m using Histogram to show the distribution of the X, Y, and Z positions of the particles. I’ve also got it to display the particle age too. Note that the number of samples (1853) shown at the bottom, actually corresponds to the number of particles.

The JScript code below features a reusable object called HistogramData. This object has a member function called ProcessSample() which will take a sample value and take care of the histogram construction for you. You then push the curHist member to the Histogram COM application for display.

The first function in the code is a script callback for a particle event. To make it work, you just need to add a particle event to a PType and create an OnEveryFrame event with the trigger value set to 0 so that the script gets called every frame. You can then control the execution of the Histogram display inside the script by changing the trigger frame number.

You can download and find out more about Histogram by following this link:

www.andynicholas.com -> Histogram

Please feel free to modify this code for your own usage.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151

var HISTOGRAM_RES = 256;
var INV_HISTOGRAM_RES = 0.00390625;
var HISTOGRAM_ARRSIZE = 257;
 
function OnEveryFrame(inParticleCloud, inTriggerParticleIndices, inSimFrame)
{
//Frame 99 is when the distribution will be viewed, and
//you can change it to whatever you want.
 
//Note that if you persist the histogram data objects, there's no
//reason you can't gather distributions across multiple frames.
 
//To make things a little easier to adjust, you may also want to
//create a custom property in the scene to tie this frame value to.
 
if(inSimFrame==99)
{
//Initialise the data
var histx = new HistogramData();
var histy = new HistogramData();
var histz = new HistogramData();
var histage = new HistogramData();
 
//This is where we store the data whose distribution we want to look at.
//In this case, we're observing position and age.
 
var particles = inParticleCloud.particles;
var num_particles = particles.count;
for(var i=0;i<num_particles;++i)
{
var particle = particles(i);
histx.ProcessSample(particle.position.x);
histy.ProcessSample(particle.position.y);
histz.ProcessSample(particle.position.z);
histage.ProcessSample(particle.age);
}
 
//Display the data
var histWindow = new ActiveXObject("HistogramDisplay.Application");
histWindow.SetHistogram(histx.curHist,"Pos.X", 0, histx.min, histx.max);
histWindow.SetHistogram(histy.curHist,"Pos.Y", 1, histy.min, histy.max);
histWindow.SetHistogram(histz.curHist,"Pos.Z", 2, histz.min, histz.max);
histWindow.SetHistogram(histage.curHist,"Age", 3, histage.min, histage.max);
 
histWindow.SetHistogramColor(0, 80, 0, 0);
histWindow.SetHistogramColor(1, 0, 80, 0);
histWindow.SetHistogramColor(2, 0, 0, 80);
histWindow.SetHistogramColor(3, 0, 0, 0);
 
histWindow.SetNumToDisplay(4);
histWindow.UpdateWindow();
}
}
 
//Data object representing histogram data
//and contains member function called ProcessSample()
 
function HistogramData()
{
this.min=0;
this.max=0;
this.samples=0;
 
this.curHist = new Array(HISTOGRAM_ARRSIZE);
this.otherHist = new Array(HISTOGRAM_ARRSIZE);
 
for(var i=0;i<HISTOGRAM_ARRSIZE;++i)
{
this.curHist[i]=0;
this.otherHist[i]=0;
}
 
this.ProcessSample = function(sample)
{
//This function does all the hard work
 
//It is a direct port from C++ of the functionality
//of the original Histogram rendertree shader
 
var oldMin = this.min;
var oldMax = this.max;
var oldBucketSize = (oldMax-oldMin)*INV_HISTOGRAM_RES;
 
var scaleChanged=false;
 
if(this.samples==0)
{
this.min = sample;
this.max = sample;
this.samples++;
return;
}
 
if(sample<this.min)
{
this.min = sample;
scaleChanged=true;
}
else if(sample>this.max)
{
this.max = sample;
scaleChanged=true;
}
 
if(this.samples==1)
{
this.curHist[0]++;
this.curHist[HISTOGRAM_RES]++;
this.samples++;
return;
}
 
var bucketSize = (this.max-this.min)*INV_HISTOGRAM_RES;
 
var rangeRatio = HISTOGRAM_RES/(this.max-this.min);
if((this.max-this.min)==0) rangeRatio=0;
 
if(scaleChanged)
{
//Swap histograms
var tempHist;
tempHist = this.curHist;
this.curHist = this.otherHist;
this.otherHist = tempHist;
 
//Copy and rescale the histogram according to the new sample and resample
for(var i=0;i<HISTOGRAM_ARRSIZE;i++)
{
//Calculate sample value
var value = oldMin + oldBucketSize*i;
 
//Calculate new bucket
var newBucket = Math.floor((value - this.min)*rangeRatio);
 
if(newBucket<0) newBucket=0;
if(newBucket>=HISTOGRAM_ARRSIZE) newBucket=HISTOGRAM_ARRSIZE-1;
 
this.curHist[newBucket]+=this.otherHist[i];
this.otherHist[i]=0;
}
}
 
//Add sample
var inputBucket = Math.floor((sample - this.min)*rangeRatio);
if(inputBucket<0) inputBucket=0;
if(inputBucket>=HISTOGRAM_ARRSIZE) inputBucket=HISTOGRAM_ARRSIZE-1;
this.curHist[inputBucket]++;
 
this.samples++;
}
}

I was required to create a bubble stream behind an underwater torpedo. Do torpedoes really have a stream of bubbles behind them in real life? In movies they do, so the question doesn’t really matter. I wanted to have many small bubbles and a few big bubbles within the same PType. I wanted to have the big bubbles rise faster than the small ones. I also wanted the bubbles to wobble as they were rising, and the wobble to be function of the size and the speed. Finally, I wanted the sprite sequence to begin at a random frame and continue normally as the particle aged. All this is not possible with the actual particle system in XSI 5.11, although they are common requirements in a simulation scene.

The Distribution problem.
In XSI, you can only choose from uniform and Gaussian distribution. This means you can only have a middle value, and an equal probability on each side. For what we need here, we will create a scripted event with the trigger on “Particle Age” at zero. We will name the event “BirthControl“. In the script tab, we set the language to JScript. It’s a shame we can’t use Python, since there are many cool random distributions in the standard library. The ScriptContext will be set to “Per Trigger Particle”. An exponent function will give a random distribution with a high probability at one end and a progressively lower probability towards the other end.

Size = (random number)5 * 0.025 + 0.005
The “* 0.025″ sets the difference in size between the biggest and the smallest bubbles.
The “+ 0.005″ sets the size of the smallest bubble size at 0.005 units. The biggest bubbles will be 0.03 units big.

In JScript, it’s written like this:

1

inParticle.Size = Math.pow(Math.random(), 5) * 0.025 + 0.005;

The object inParticle is given to the script by XSI and contains the current particle that triggered the event.

The Speed from Size problem.
The size of the particles can be determined randomly. The effect of gravity can also be variable among the particles. But we can’t set a relation between the two with the tools in the UI. In fact, in scripting we don’t even have access to the effect of forces per particle. We will need to limit the length of the velocity vector according to the size of each particle. We must create a new scripted event called “PerFrameControl” with the trigger at “Every N Frame” and the value at 1. The ScriptContext will be “Per Particle”.

If a particle’s speed exceeds the product of it’s size and a coefficient, bring it back to that product.

1
2
3
4
5
6
7

speed = inParticle.Velocity;
size = inParticle.Size;
if (speed.Length() > size * 10) {  // if speed is bigger than 10 times the size...
    speed.NormalizeInPlace();      // scale the speed to be 1 and
    speed.ScaleInPlace(size * 10); // scale speed to be 10 times the size.
}
inParticle.Velocity = speed;

This has the advantage that a particle will have no speed at its birth, and slowly accelerate from the effect of gravity. It will continue to accelerate until it reaches the speed it is allowed. Then it will keep this speed forever unless it has to decelerate, which shouldn’t happen in our scene.

The Wobble Problem
There is already some perlin noise in the PType to make the bubbles rise in a natural fashion and we don’t want to lose that. We can’t add a small brownian noise to simulate the wobble and even if we could, we couldn’t link it to the size and speed of the particles. Without going into complicated wobble behavior, we will simply randomize the particle position in X and Z over time.

Generate a vector that has a random value for the X and Z axes, and multiply that value by the size and the speed. Add that vector the the particle’s position.
In the PerFrameControl event, we add:

1
2
3
4

pos = inParticle.Position;
wobble = XSIMath.CreateVector3((Math.random() - 0.5) * size * speed.Length(), 0, (Math.random() - 0.5) * size * speed.Length());
pos.AddInplace(wobble);
inParticle.Position = pos;

The big particles will wobble more than the small ones, and all particles will wobble progressively more as they gain speed.

The Sprite Sequence Problem.
We have a sequence of images of a bubble rising to the surface to apply on the sprite shader of the particles. It is 100 frames long. There are many choices for the behavior of the sprite sequence on the particles, but an important one is missing. We want each particle to choose a random frame in the sequence at its birth, and take the next frame of that sequence at each frame it ages. For this, we need to create a new User Parameter on the PType. We name it “BeginSpriteSeq” and set its type to Integer.

We set this parameter to a random value between 0 and 100, the length of the sequence, on each particle. In the BirthControl event, we add the following line:

1

inParticle.Attributes("BeginSpriteSeq").Value = Math.random() * 100;

Then, we need to tell the particle to choose the next frames over time. In the PerFrameControl event, we add the line:

1

inParticle.SpriteIndex = inParticle.Attributes("BeginSpriteSeq").Value + inParticle.Age;

I know there are ways to fake this in the render tree but the pseudo-random value is not very easy to obtain and it makes a recipe that is more complicated to update from one situation to another. However, contrary to the scripted event solution, it does not increase the simulation time.

The Result.
After all the work, we end up with only two events that solve all the problems encountered with a reasonable simulation time.

BirthControl event
trigger: Particle Age = 0
ScriptContext: Per Trigger Particle

1
2

inParticle.Size = Math.pow( Math.random(), 5 ) * 0.025 + 0.005;
inParticle.Attributes("BeginSpriteSeq").Value = Math.random() * 100;

PerFrameControl event
trigger: Every N Frame = 1
ScriptContext: Per Particle

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//speed control
speed = inParticle.Velocity;
size = inParticle.Size;
if (speed.Length() > size * 10) {  // if speed is bigger than 10 times the size...
    speed.NormalizeInPlace();      // scale the speed to be 1 and
    speed.ScaleInPlace(size * 10); // scale speed to be 10 times the size.
}
inParticle.Velocity = speed;
 
//wobble
pos = inParticle.Position;
wobble = XSIMath.CreateVector3((Math.random() - 0.5) * size * speed.Length(), 0, (Math.random() - 0.5) * size * speed.Length());
pos.AddInplace(wobble);
inParticle.Position = pos;
 
//sprite sequence
inParticle.SpriteIndex = inParticle.Attributes("BeginSpriteSeq").Value + inParticle.Age;

Here is a Quicktime movie of the result.
Here is a close-up from the HD version.

In the final version of this recipe, I had to change the script context of the events because I wanted to add a custom PPG on the cloud with some parameters to control the various effects. This required a Dictionary.GetObject() to get the values of those parameters in each event and I didn’t want to evaluate it for each particle. I set the script contexts to Per Cloud, and did some conditional expressions to replace the triggers.

I’m glad we can solve these problems since they occur surprisingly often in production. However, I wish the solutions were more accessible from the UI. Not only would it make it easier for an artist to use them, but also the simulation times might be decreased since it would be part of the internal solver. I hope the good people at Softimage consider those problems in the new particle system they are preparing. The ability to customize the distribution of random values on a parameter is essential to a good simulation package. So is the ability to link random values from one parameter to another.

1
2
3
4

var world = engine.GetCurrentWorld();
world.AddPropertyTable();
world.ChanceOfRainInWorld = 0.8;
Console.PrintNl(world.ChanceOfRainInWorld);

I use this profusely, especially with my actors. This way I can tack on actor characteristics (i.e.: agression level, strength, sight distance, etc) and refer to these characteristics later in the code.

Actor Caching

Once you’ve distributed your actors in the world and you’ve given them characteristics you may need to save these characteristics for future simulations. I built a little helper file that contains two functions to save and retrieve an actor cache. You can then, in your Piccolo startup, load a world with only your environment, and load your actors from this cache that will recreate the property table as it was when you saved the cache. Right now the code only supports saving and retrieving String, Integer and Float values because that’s what I needed. If you build on this code and add types, I’d appreciate your contributing back to the community.

The other benefit of this is that you can create your population distribution in XSI along with your actor characteristics, output an actor cache that can then be read back into Behavior as the initial state of your simulation.

Motion Caching

There are also two functions to do home-brewed motion caching. The same kind of thing Behavior does with DrvMotion. The only advantage is that it takes the black out of black-box and you know how the cache is built and what the file format is. It’s more of a Behavior/Piccolo exercise than anything else. It is definitely slower than DrvMotion because it is pure Piccolo.

You can download an example project (Behavior 2.1) and check out the code.
Any comments would be very welcome!

Warning: If you’ve never used Behavior before or don’t care for crowd sim, skip this one. If you care for a stupid Behavior trick… Read on…

Behavior has a rendering pipeline that involves spewing a bunch of files into a directory and rendering them out with a nifty geometry shader and Mental Ray. Thing is, you have to run a simulation for every render pass you have. This means, you don’t have a choice but to cache your actor’s motion data in a first pass and then simulate all your other passes using the cache to output your .mi2 files.

When I did all this I wound up with characters that wouldn’t render at exactly the same spot from pass to pass even if I had used a caching mechanism. We’re talking pixels here but it was enough to show…

Ever notice all those .mrd files Behavior creates along with your .mi2 files? They contain your actor positions for every frame of your simulation. To get my passes properly aligned I just copied all the .mrd files from the output directory of one simulation into the output directory of another and voila!

I’m wondering if this is just a cosmic fluke that should be chaulked up to planetary alignment or if it’s a legal Behavior move but… It just saved my butt!

Carry on!

Simulations

You can deduce the units of a parameter rapidly with only a few tries. The Age of a particle is expressed in seconds, not frames. The Size of a particle is in scene units, not pixels. Starting from that, we can assume that the Rotation Velocity is in degrees per seconds, not degrees per frame, and that the Allowed Linear Velocity is expressed in units per seconds.

Things get a little more tricky when you want to animate a parameter according to the age of a particle. The key you set at frame 50 doesn’t mean 50 seconds, but 50 frames. This is not consistent with the other examples stated above, but it’’s a lot easier to figure by yourself as it’s more intuitive.

For a rigid body object, the help file says the Linear Velocity Limit is in units. Of course, experimentation shows it’s in units per seconds. Setting the Angular Velocity Limit is awkward. The help file says the value is expressed in radians. Experimentation suggests it’s in degrees per 2 seconds!

1
2
3
4
5
6
7
8

CreatePrim "Cube", "MeshSurface"
CreateActiveRigidBody "cube"
SetValue "cube.DynamicsInitState.angvelz", 90
SetValue "cube.RigidBodyProp.VelLimitsActive", True
SetValue "cube.RigidBodyProp.AngVelLimit", 60
SetValue "PlayControl.Format", 7
SetValue "PlayControl.Out", 25
PlayForwardsFromStart

After one second of simulation, the rotation is roughly half of the Angular Velocity Limit.

Displacement

Rendering parameters can also cause a considerable amount of confusion. Displacement and Final Gathering both have parameters that can be switched between absolute and camera view reference. In the Displacement tab of the GeoApprox PPG of an object, when set to Fine, there is a parameter called Length. This parameter is expressed in scene units. Mental ray will try to keep the triangles no bigger than Length. You must adjust this parameter to the scale of your object or scene. The render time can go through the roof if you activate View Dependent without modifying the value of Length because its units have changed. It’s now expressed in pixels, making the size of the triangles dependent on the distance to the camera, and in this case, smaller than half a pixel by default.

Final Gathering

The same goes for the Min and Max Radius in the Final Gathering tab of the Render Options PPG. Their values are normally expressed in scene units. When you click on the Automatic Compute button, XSI calculates the average bounding box size of all the objects in the scene in scene units and sets the two parameters accordingly. However, when you activate the View Dependent check box, the values of the radius are now in pixels. If you click on the Automatic Compute button, it will still calculate the values in scene units, and set the wrong values in the parameters, possibly increasing render time considerably and unnecessarily.

Volume Effects

I’ve seen many artists having problems with the Volume Effects shader. This is a fine shader even if it hasn’t evolved a lot since its early days in Soft|3D. It has a parameter called Step Size, which controls the spatial resolution of the marching algorithm. It’s expressed in scene units so it is very dependent on the scene scale. Applying this shader on a pass in a very big scene can lead to nightmares in terms of rendering time. It’s important to understand this parameter when using the Volume Effects shader, and the fact that its units are in scene units scaled by the size of the object it’s applied on. If you apply it to a scaled up cube (scaling = 100, 100, 100), the Step Size will be expressed in scene units * 100.

Depth of Field

The Depth of Field Shader is particular. Many of its parameters names say they are in inches, when in fact they are in scene units. I suppose the developer wanted us to use a scene scale of 1 unit = 1 inch to make sure the result would match reality. I don’t think this was a very good idea. It confuses more than anything.

I wish Softimage could add some space or some tooltips in PPGs to display the units. It would help the users determine the best values for certain parameters without having to go in the documentation all the time. In the mean time, experimentation is still our best resource.

As I usually approach these kind of problems by completely rewriting something, I rewrote the hair dynamics from scratch. The result is a flexible, animatable and controllable hair dynamics system, which I’d like to present in this article.

The system works using vector fields for each segment of the hair, respectively each segment of a curve. Each vector’s force can be controlled along the hair using Softimage XSI’s fcurve editors for property pages (PPG). There are two curves for each parameter, so you can blend between two different setups and animate the blends.
The dyn_ctrl PPG has control over the following parameters:

stiffness: Controls how much each hair segment tries to straighten based on the previous segment.
flex: Controls each segment’s movement along the hair. This prevents bending and gives the hair a floaty look, esp. for underwater shots.
damp: This scales the simulation for each segment down, which enables the hair to move more or less depending on the setting.
density: Positive values allow clumping for each segment, negative values prevent hair segments to intersect using an avoidance algorithm.
Grav: Controls the amount of gravity force for each segment.
Wind: Controls the segments’ amount of wind influence.
Groom: Enables a force which makes the hair try to go back to its originally groomed position. Really good for tufts.
Tips: Uses each hair’s tip controller’s position as an additional attractor force per segment. This way the hair’s dynamics can be totally rigged.

All parameters are mappable to a weightmap, so you can get maximum control over each guide hair. The whole engine can be applied to just curves, so you do not need to use hair to get the dynamics working (as seen in the tree example movie).

All the different features can be seen in the following example movies:

Teaser (30 MB Sorenson 3 Quicktime)

Character with long hair and alot of wind (2.4 MB Sorenson 3 Quicktime)

Character with a mohawk kind of tuft (2.1 MB Sorenson 3 Quicktime)

Tree with chains enveloped to curves with dynamics (1.6 MB Sorenson 3 Quicktime)
(Tree setup by Adam Ferrall)

I hope you enjoy watching the movies, and let me know what you think!

best,

-H

this beeing my first article here, I’ll write about something I just discovered the other day.

The problem

We use tons and tons of particles for trees to instance leaves. I am talking about numbers like 120.000 particles per tree, to get a convincing look for the leavework. When you have such a particle cloud in a XSI model, freeze it and reload it a couple of times, you get different results after loading it in, which is a huge problem for our renderfarm. I tried to use the initial state to “freeze” the initial state of the particle-cloud, without success though.

The workaround

Write your own particle-cloud initial state! I tried different methods using javascript to read the data from the particle-cloud, store it into a userdatablob and read it back on sceneload/modelimport. It worked, but was slow as hell. So I ended up implementing a compiled custom command (using the command wizard for Visual Studio 6.0) which creates a structure storing arrays for all the different parameters for each particle (position, rotation, size, color….) and converted that into a userdatablob-friendly character array.
To read the data back onto the particle-cloud I used a compiled operator, which is evaluated once (either on scene-load or model-import), which works the same way (converting character array to the structure, reading back all the values from the different arrays).

This successfully restored the particle cloud in its frozen state.

More to come!