PhysX InterCollision Test

Additional Notes

First, what PhysX InterCollision does not do. It does not control whether particles collide with each other. Just by default, if particles participate in a PhysX simulation, and they have their collision shape defined with a PhysX Shape operator, they do collide with each other - this is an integral part of simulation.

PhysX InterCollision test serves the purpose of registering inter-particle collision, and redirecting particles (according to the collision information) to other events.

Adding a PhysX InterCollision test to an event is somewhat similar to turning On Test True If Particle option in PhysX Collision test - the plug-in starts collecting the information about collisions. As with PhysX Collision test, the job of collecting this information does take toll on the CPU resources; so, if you don't need to redirect particles to other events on the fact that they collide with each other - then don't add the test.

Collision Registration With group defines collisions of what group of particles to register. By default, it's set to Particles In Current Event - it means that if a particle in the current event collides with another particle in the current event, the collision is registered and processed. Depening on other options (Test True If Particle), the collision may or may not make a particle to test as True. Regardless of the outcome, only the collisions between particles in the current event are processed if the option is set to Particles In Current Event.

Alternative option is Particles In Other Events. There, you can define what other events, in term of collision registration, you are interested in. The list below the option has all events in the current particle system (under the same PF Source global event, since a simulation can run on per PFlow 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 select the events (make them dark blue) to identify what events for collision are needed.

To illustrate the point about Collision Registration scope, let's consider the following example: PhysXInterCollision01.zip

In this example, at inital stage all particles form a box, and they fall down on a torus deflector. The first event Event 01 has two tests: PhysX Collision to define collision with the Torus deflector, and PhysX InterCollision to define jump to the next event when particles collide with each other. Keep in mind that Collision Registration scope is set to Particles In Current Event. Therefore, it possible to some unlucky particles not to collide with any other particles before all neighbors already collide with each other and being transferred to the next event. As you can some, 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 make a transition to the next event, you need to change the Collision Registration scope to Particles In Other Events, and mark all three events in the list: Event 01, Event 02, Event03. Now, if you play the animation, you can see that all particles get a collision notification, and get from green to yellow to blue.

One more note about the example PhysXInterCollision01.zip. Once particles get to the last event, they become static by turning the simulation Off (see PhysX Switch operator in the last event). The static nature of these particles put some particles that are "left behind" (the green ones) into impossible situation - they are squeezed between static particles, and there is no enough room for their placement. That is why you can see jitter motion in the green particles.

You can avoid this jitter by adjusting the PhysX Switch operator in the last event. Instead of turning simulation Off, you can turn On Match Position. This way, particles from the last event and the first one, all participate in simulation, they are, in a sense, equal for simulation - all are dynamic. Therefore, some "spare room" is available for the green particles, and an equilibrium placement is achievable.

Let's look at another example - PhysXInterCollision02.zip - to illustrate the difference between Collides and Collided Multiple Times options in Test True If Particle group. In this example, we have 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 zero. The speed and spin values are set by regular PFlow operators (Speed 01 and Spin 01), but to make particles static, a PhysX 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, you need decrease # Times value to find how high this value can be while ensure all particles to be transfered to the next event. This value is the least amount of times a particle collides with other particles during the animation. Also, pay attention that Collision Registration scope is set to Particles In Other Events, with all events as selected. It means that in this particular animation we count all interparticle collisions.

With our last example - PhysXInterCollision03.zip - we can illustrate usage of Report To Data Operator and Additive Count options. Here, both these options are set On. It means that the test, while registering all collisions as defined in Collision Registration scope, reports it as an integer data channel to be used by a Data Operator. Note that PhysX InterCollision test is not wired to anywhere, but below the test there is a Data Operator - see the Data Flow of this Data Operator on the left side. In this Data Operator, there are Input PhysX sub-operators on the top. One of them counts all collisions with deflectors (in this case, it's the Torus deflector), while the other counts all inter-particle collisions. Both these values are summarized, and used as a relative offset for a mapping with a texture gradient. This way, the more a particle collides, the lighter it becomes.

Additional note on Report To Data Operator usage. In the example above, 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 the collision counting, in comparison with the other choices. The # Times parameter value does not make any difference for the accuracy though.

Final note on this example: the playback speed in viewport is quite slow as compared with the first two examples. This is mostly due to the rendering in the viewport since viewport takes quite a while to update the particles the changing color. If you change Display operator to Ticks, you can see significant speed up in playback - but you won't see the wonderful color change that particles have during the animation.

Options Is Slow... and Is Fast... are similar to the same named options in PhysX Collision and a regular Collison tests.

Note: since PhysX InterCollision test does not control whether particles collide with each other, and particles do collide with each other if they are in a simulation; a question pops up - how to force particles from different events not to collide with each other? It can be done with proper usage of Collision Group parameter in the corresponding PhysX Shape operators, and adding a collision exclusion pair in PhysX World helper for the simulation.