Контроль значений particleId | 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.

Суть в том, что рождающиеся частицы по particleId равномерно привязывались у меня экспрешеном к поверхности, а теперь начали возникать непонятно где по краям. Не вдаваясь в детали конкретного сетапа, общая ситуация следующая:

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:

Когда мы создаем частицы, настраиваем их поведение множеством пробных симуляций и наконец-то создаем initial state, диапазон  значений particleId обычно начинается с нуля и заканчивается порядковым номером последней родившейся частицы. Тут все просто и понятно.

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.

Затем мы захотели стереть этот initial state, пересимулить частицы и запечь новый. Ставим, как обычно, Lifespan Mode в Constant и значение Lifespan в ноль – симулим фрейм и все частицы в агонии умирают – ставим initial state и получаем, казалось бы, обнуленную систему частиц. Но если нагенерить новые частицы и посмотреть их particleId, окажется, что он продолжается с последнего номера только что убиенных точек.

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.

Обычно это не проблема, но в моем случае, когда я поочередно привязывал каждую частицу к определенной uv-координате поверхности, предполагая, что particleId начинается с нуля, экспрешен начал привязывать их к запредельным координатам и все развалилось.

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.

Решение довольно простое – у частиц есть атрибут nextId, который хранит число для particleId следующей предполагаемой частицы. И у этого атрибута есть initial state версия, которая и запоминается при сохранении initial state частиц. Несмотря на то, что Майя будет клясться мамой, что такого атрибута у нее нет (его вроде видно только при listAttr, создании нового с таким же именем и, как ни странно, в доках), его надо занулить… Точнее его initial state версию (в целом об этом в моем предыдущем посте – http://www.sigillarium.com/blog/678/ ):

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;

После перезапуска симуляции particleId начнется с нуля.

After the rerun of the simulation particleId starts with zero.

Подобным же образом можно контроллировать докэшивание частиц, которое наоборот может создавать новые частицы с particleId начиная от нуля (в итоге получается кэш, в котором есть частицы с одинаковым particleId – это вызывало, к примеру, проблемы при конверсии инстансера в геометрию моим скриптом – http://www.sigillarium.com/blog/726/ )

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/ )

Можно создавать частицы с одинаковыми particleId или по определенному алгоритму. Тут уже понятия не имею зачем это может быть полезным, но по-любому забавно 🙂

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 2013.09.01 at 10:32
    Permalink

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

Subscribe to comments via RSS

Leave a Reply