Indices are created with a few rules in place:
1) they are assigned in order of birth
2) they do not necessarily correspond to birth ID (they may be pushed to random places in the overall particle system where deleted particles are found)
3) they remain the same for any given particle until the particle is deleted
Further explanations of those rules:
If event001 spawns 3 particles and event002 spawns 3 particles, the sim indices will look like this:
If you then delete event001, the indices will look like this:
If you create a new event and rename it event001, the indices will look like this (birth operators are processed in order of event creation, not based on event name!):
If you then take that previous setup (where event001 was created/renamed after event002 was created) add an operator to event002 that deletes its second particle, the indices will look like this:
So my previous post represents the simplest case, where you don't delete any particles and the particles are birthed in order. More complex cases may require you to track particles by their ID instead of their sim index in order to match them up. A particle's ID never changes and is never assigned to more than 1 particle in the flow....whereas a sim index can be assigned to more than 1 particle, if the original particle is deleted and thus a new particle takes it (note: neither sim index or ID will ever be assigned to more than 1 living particle at the same time).
1) they are assigned in order of birth
2) they do not necessarily correspond to birth ID (they may be pushed to random places in the overall particle system where deleted particles are found)
3) they remain the same for any given particle until the particle is deleted
Further explanations of those rules:
If event001 spawns 3 particles and event002 spawns 3 particles, the sim indices will look like this:
Code:
0 //event001, particle 1, ID 0
1 //event001, particle 2, ID 1
2 //event001, particle 3, ID 2
3 //event002, particle 1, ID 3
4 //event002, particle 2, ID 4
5 //event002, particle 3, ID 5If you then delete event001, the indices will look like this:
Code:
0 //event002, particle 1, ID 0
1 //event002, particle 2, ID 1
2 //event002, particle 3, ID 2If you create a new event and rename it event001, the indices will look like this (birth operators are processed in order of event creation, not based on event name!):
Code:
0 //event002, particle 1, ID 0
1 //event002, particle 2, ID 1
2 //event002, particle 3, ID 2
3 //event001, particle 1, ID 3
4 //event001, particle 2, ID 4
5 //event001, particle 3, ID 5If you then take that previous setup (where event001 was created/renamed after event002 was created) add an operator to event002 that deletes its second particle, the indices will look like this:
Code:
0 //event001, particle 1, ID 0
1 //event002, particle 1, ID 3
2 //event001, particle 3, ID 2
3 //event002, particle 2, ID 4
4 //event002, particle 3, ID 5So my previous post represents the simplest case, where you don't delete any particles and the particles are birthed in order. More complex cases may require you to track particles by their ID instead of their sim index in order to match them up. A particle's ID never changes and is never assigned to more than 1 particle in the flow....whereas a sim index can be assigned to more than 1 particle, if the original particle is deleted and thus a new particle takes it (note: neither sim index or ID will ever be assigned to more than 1 living particle at the same time).