I’m getting some rather odd behaviour with exporting particle paths.
If I grab the path of a particle over its lifespan using particlePosition it eventually exhibits random popping behaviour, which results in a smooth, then suddenly violently jagged spline.
However, if I use particlePositionById, its as expected – a smooth path from start to finish.
The thing is, in the viewport the animation is perfect. When the crazy popping occurs, it does NOT match the animation. Also, the exported spline has exactly the same amount of knots as there are frames (just in case there were any extra calculations going on).
I’ve inherited the particle system off another animator who has used a (fairly simple) birth script to set the particles’ ultimate destination to a grid formation, which uses a find target to resolve itself.
Are these two issues (birth script and particlePosition craziness) connected, and if so, why does particlePositionById NOT exhibit this behaviour?
(the other option is that there’s a bug. But I doubt that – it’s most likely my lack of PFlow scripting knowledge!)
Thanks,
Dave
ps. In the image, not all of the original particles make up the grid, which is my it looks like it’s looping back on itself.
Are particles sent out to another event by the Find Target test? That would explain what you are seeing and wouldn’t be surprising at all.
In short:
*The particleIndex variable describes the index of a particle inside a specific particle container.
*Particles inside a container are numbered without gaps from 1 to N.
*Any particle from the container can move to another container (event), causing a renumbering of all particles with higher index in the original container.
*Accessing the whole PFlow’s particles by index gives you a sum of all containers without gaps, so each time a particle changes from one event to the other, indexes change within the top PFlow Emitter’s container.
In short, using the particleIndex is a good idea ONLY WITHIN A CONTAINER as the order is not guaranteed otherwise. Script Operators iterating over particles inside an event have no problem using particleIndex, but external scripts working on the system as a whole are in danger if particles are being added, removed or moved between events (which is the typical case in most systems).
The particleID on the other hand is given to each particle at birth and is UNIQUE and NON-CHANGING throughout the particle system’s life and all its containers. A particle born as ID 42 will keep that ID independent of what container it is moved to.
So if you have anything but the simplest FPlow with Emitter and ONE Event, using the particleIndex to access particles of the whole system will cause “jumps” in the position values because of index renumbering. Use the *byID() methods for property access to get the desired results – for each particle by index, get the corresponding ID first, then use that ID to ensure the correspondence to any external data like spline vertices, mesh vertices, baked nodes and so on.
Hope this helps.
Hello Bobo,
As always your replies are informative, authorative, and very helpful! Thank you.
On a side note, the design company I’m doing this job for have been using krakatoa for their particle exports (to a csv file per frame, they tell me) but upon parsing the files to get a path per-particle, they were also getting this popping effect (which is why they got me in!)
As I said, their flow is about 4 or 5 seqeuential events, nothing too complex, but do you know any reason that Kackatoa would cause particles to (in their words) “swap positions”?
I can get you more information if you need it.
Thanks,
Dave
Sure, Krakatoa calls PFlow and tells it “Give me your particles”. So the list of particles it writes out to CSV or PRT is sorted in the same order you would get if you would iterate from 1 to the number of particles in the PFSource using MAXScript – it is a concatenation of all particle containters connected inside the flow, and if a particle jumps to another event, it jumps inside the list to a different row.
The solution is to add the ID channel to the output (which will have a rather prominent use in Krakatoa 1.1 as we allow now the loading of dynamic CSV and PRT sequences back into PFlow based on the ID). It will list the “Born ID” of the particle. One could use it to identify the particles by their unique IDs and ignore the sorting of the CSV file.
Aha. Thanks for the info.
The word “buggy” has been mentioned a few times, so I’ll be glad to put them straight! Great for me though, as it’s got me a couple of days scripting PFlow!
All the best,
Dave
In short:
*The particleIndex variable describes the index of a particle inside a specific particle container.
*Particles inside a container are numbered without gaps from 1 to N.
*Any particle from the container can move to another container (event), causing a renumbering of all particles with higher index in the original container.
*Accessing the whole PFlow’s particles by index gives you a sum of all containers without gaps, so each time a particle changes from one event to the other, indexes change within the top PFlow Emitter’s container.
This was great information, Bobo.
Is there something similar in the documentation, perhaps a section that describes the “anatomy” of a particle flow, with regard to scripting? Or is it just a case of reading and digesting the “How to”s?