This topic presents additional information on usage of the mParticles InterCollision test in Particle Flow.
First, what mParticles InterCollision does not do: It does not control whether particles collide with each other. By default, if particles participate in a MassFX simulation, and their collision shape is defined by an mParticles Shape operator, they collide with each other. This is an integral part of the simulation.
The mParticles InterCollision test registers interparticle collision, then redirects particles (according to the collision information) to other events.
Adding an mParticles InterCollision test to an event is akin to turning On Test True If Particle option in the mParticles Collision test: Particle Flow starts collecting information about collisions. As with the mParticles Collision test, the job of collecting this information takes a toll on CPU resources, so if you don't need to redirect particles to other events based on their colliding with each other, then don't add the test.
Use the Collision Registration With group to define which collisions of specific groups of particles to register. By default, it's set to Particles In Current Event. This means that if a particle in the current event collides with another particle in the current event, the collision is registered and processed. Depending on other options (Test True If Particle), the collision may or may not cause a particle to test as True. Regardless of the outcome, if the option is set to Particles In Current Event, only collisions between particles in the current event are processed.
The alternative option is Particles In Events. Here you can define other events, in term of collision registration, you are interested in. By default, the list shows all events in the current particle system (under the same PF Source global event, since a simulation can run per Particle Flow particle system only). Keep in mind that the list also has the current event entry. So if you need to register collision with a set of events, including the current one, you can do that. Since all events are already listed, you need to highlight the events (make them dark blue) to identify what events for collision are needed.
To illustrate the point about the collision Registration scope, consider the following example: MassFXInterCollision01.max.
In this example, at first all particles form a box, and then fall onto a torus deflector. The first event, Event 01, contains two tests: mParticles Collision to define collision with the torus deflector, and mParticles InterCollision to define jump to the next event when particles collide with each other. Keep in mind that the Collision Registration scope is set to Particles In Current Event. Therefore, it possible for some unlucky particles not to collide with any other particles before all neighbors already collide with each other and are transferred to the next event. As you can see, in this configuration there are particles that are "left behind," and stay green in color (as in the first event).
To make all particles eventually transition to the next event, change the Collision Registration scope to Particles In Events and highlight all three events in the list: Event 001, Event 002, and Event 003. Now when you play the animation, every particle gets a collision notification and changes from green to yellow to blue.
One more note about the example MassFXInterCollision01.max: Once particles get to the last event, they become static by turning off the simulation (see the mParticles Switch operator in the last event). The static nature of these particles put some particles that are "left behind" (the green ones) into an impossible situation: They are squeezed between static particles, and there is no enough room for their placement. That is why you can see jittering motion in the green particles.
You can avoid this jittering by adjusting the mParticles Switch operator in the last event. Instead of turning off the simulation, you can turn on Match Position. This way, particles from the last and first events all participate in simulation. They are, in a sense, equal for simulation purposes: All are dynamic. Therefore, some "spare room" is available for the green particles, and an equilibrium placement is achievable.
To illustrate the difference between the Collides and Collided Multiple Times options in the Test True If Particle group, look at another example: MassFXInterCollision02.max. This example contains two events, and particles are redirected to the second event if they collide with each other 15 times, according to # Times option. In the next event, particles are set to be static: Speed and Spin are equal to 0. The Speed and Spin values are set by regular Particle Flow operators (Speed 01 and Spin 01), but to make the particles static, a mParticles Switch operator is used.
If you play the animation, you can see that not all the particles were able to get the second event. This is because some of them did not collide at least 15 times during the course of the animation. As an exercise, decrease the # Times value to find how high this value can be while ensuring that all particles are transferred to the next event. This value is the smallest number of times a particle collides with other particles during the animation. Also, note that Collision Registration scope is set to Particles In Events, with all events highlighted. In this example, that means that we count all interparticle collisions.
The last example, MassFXInterCollision03.max, illustrates usage of the Report To Data Operator and Additive Count options. Here, both of these options are on. This means that the test, while registering all collisions as defined in the Collision Registration scope, reports them via an integer data channel to be used by a Data Operator. Note that the mParticles InterCollision test is not wired to any event, but below the test there is a Data operator. The Data Flow of this operator, shown on the left side of the following illustration, includes Input mParticles suboperators at the top. One of them counts all collisions with deflectors (in this case, it's the Torus deflector), while the other counts all interparticle collisions. Both these values are summarized and used as a relative offset for a mapping with a texture gradient. That way, the more times a particle collides, the lighter its color.
A note on Report To Data Operator usage: In this example, while the test is not wired to anywhere, the Test True If Particle option is set to Collided Multiple Times. This option gives the most accurate result in counting collisions, compared with the other choices. The # Times parameter value does not make any difference for the accuracy though.
An additional note on this example: The playback speed in viewport is slow compared to the first two examples, mainly because the viewport takes a while to update the particles' changing colors. If you change the Display operator to Ticks, you'll see a significant improvement in playback speed, but you won't see the particles change color during the animation.
The Is Slow After Collision(s) and Is Fast After Collision(s) options are similar to the options of the same names in mParticles Collision and regular Collision tests.