Controlling particleId values

Almost finishing the working day and planning to send a scene for overnight rendering, I’ve discovered with regret that pretty laborious several-days particle setup has gone terribly wrong. Before my eyes began to appear the images of a dinner first cooling down and then completely gone… of a couch slowly drowning in the haze of non-existence… of the first sun beams streaming through the blinds of the office window… But all these romantic moments were meanly interrupted by the discovery of the problem and it’s unbelievably quick solution.

The thing is, that newborn particles in my setup get uniformly attached via expression to the surface by their particleId, and now they’ve started to bunch up somewhere in the corners and so on. Without getting into the specifics of my particular setup, the overall situation is like this:

When we create particles, tune their behavior with a lot of test simulations and, at last, set an initial state, the range of particleId values usually starts with zero and ends with the order number of the last particle emitted. That’s pretty obvious and clear.

Then we’ve decided to erase this initial state, re-simulate particles and set a new one. As usual, we set Lifespan Mode to Constant and Lifespan to zero – simulate a frame and all particles perish in agony – set initial state and get, it would seem, a fully reset particle system. But if we generate new particles now and look at their particleId, we’d find out that it’s values continue just murdered ones.

Usually this is not a problem, but in my case I sequentially attach each particle to a specific surface uv-coordinate, presuming that particleId starts with zero, and expression has begun to stick them to non-existing coordinates and everything went down.

The solution is pretty simple – particle shape has nextId attribute, that keeps the value for particleId of the next possible point. And this attribute has initial state version, that gets saved by setting initial state for particles. Although Maya will swear it doesn’t have this attribute (it’s visible only in listAttr callback, in error while trying to create a new attribute with this name and, strangely enough, in docs), we need to zero it out… Actually, it’s initial state version (on this in general see my previous post – http://www.sigillarium.com/blog/678/ ):

setAttr .nextId0 0;

or even shorter:

setAttr .nid0 0;

After the rerun of the simulation particleId starts with zero.

The same way we can control additional caching to existing one that, vice versa, can create new particles with particleId starting with zero (and as a result we get a cache that has more that one particle with the same particleId – it produced some problems with my instancer to geometry conversion script, for example – http://www.sigillarium.com/blog/726/ )

We can create particles with the same particleId or a specific pattern. I can’t imagine the usefulness of this now, but that’s cool anyway 🙂

Posted on September 25, 2010 at 19:05 by · Permalink
In: FX · Tagged with: , , , , , ,

One Response

Subscribe to comments via RSS

  1. Written by Sean Wagstaff
    on 1 September 2013 at 10:32
    Permalink

    Huge help. Was scratching my head to find this. Thanks.

Subscribe to comments via RSS

Leave a Reply