I was using a lot of TP with PRT recently, and was confronted with quite a lot of problems in terms of Index and ID changing on the particles.
It seems to me that the Index is based on group order of particels inside TP. So in a group tree of two groups, if I keep emitting into the first group, the particles indices of the second group start getting shifted down. Do I understand this correctly?
Using ID instead seems to work better, until I start deleting particles over time. I’ve been told that TP is recycling ID’s. So I was wondering if Krakatoa by default saves out TP’s particle ‘ID’ channel, or the hidden ‘uniqueID’ channel?
We are calling the function uniqueID() in the TP SDK to get the ID of particles, so it sounds like it should be unique. Have you encountered problems with dying particles in TP producing inconsistent IDs when saved to PRTs?
Regarding Index vs. ID, in most systems incl. PFlow, Krakatoa Magma, and I guess TP, too, the Index is just a counter into the container. It counts from the first particle to the last, without gaps. If a particle moves to a different container, the rest behind it are renumbered accordingly. The total system (e.g. PFlow Source) is the combination of all containers (Events) in the system, so a particle moving between containers is changing the order of the whole system. Same with Groups in TP. In Krakatoa, the PRT file is a single stream, and a Magma added to the stack generates an Index channel on the fly (it does not exist in the PRT file) that counts through the particles as they come.
The ID channel on the other hand is supposed to be populated with a unique value for each particle at its birth, and the value should remain the same during the life of the particle, regardless of what container/group it is stored in. The ID channel of PFlow is unique, and in fact it is possible to run out of possible IDs (then PFlow stops emitting new particles). I was not aware of the two ID channel types in TP, but as I mentioned above, we are using the “unique one”…
Yes, it does help as always! It’s very appreciated.
I thought I have. But now that you mentioned that Krakatoa is calling the uniqueID(), I will double check before making any statements .
It’s likely that I made a mistake somewhere and assumed to early. I was having multiple magmaflows relying on a constant number per particle generating all kind of Indices and colors, and got little overwhelmed with Index, ID and Partitions
Concerning the Index. It’s good to know that it is being generated on the fly. I thought it’s the order the particles are being saved into the file. I guess this is the same up to the point where a PRT loads multiple partitions.
How are Thinkbox tools that generate particles dealing with constant numbers like ID’s? Do PRT-Volume or Stoke particles always have an ID?
No, it is the order they are being LOADED from the file. So if you have 2 partitions with 1 million each, it will count to a million if you load 1 partition, and to 2 million if you load 2 partitions (100%). If you load 1% Every Nth of 2 partitions, it will count to 20,000 as each partition loads every 100th particle. If you switch to first N, the first 20,000 of the first partition will be loaded and counted, and so on… It really is an increment counting as particles come in, whatever their order.
PRT Volume does NOT generate any IDs, because the particles are distributed within the current frame and have no spatial or logical connection to particles that might be generated on the next frame. So if the mesh is deforming, new particles will appear and old ones will disappear, but the ones that stay in place do not have any connection to the same position particles in the previous frame. You can copy Index into ID if you want to generate an ID channel, but it will be mostly meaningless.
Stoke on the other hand always generates IDs. They are unique and work as you would hope. They are never recycled and are stored as 64 bit Integers, so they are not limited to 4 billion entries like some other systems (according to Wikipedia, the largest Int64 is 9,223,372,036,854,775,807)
.