Collision events and filters
Collision events give you procedural control over what, when and how objects break.
During a destruction simulation, the Fracture simulator deals with large pool of different objects: input objects connected to the simulator, fragments produced during a break, passive collision objects, and many more. In Fracture, all of these different objects are handled in the same way and it is collision events that allow you to specify which objects will break under which conditions. Worded differently, collision events allow you to filter out which objects you want to break, when they should break and in what fashion.
A collision event consists out of one or more filters and breaking only happens when all the filters of a collision event satisfy. It might help to think of filters as conditionals, conditions or if-statements. In other words, breaking only happens if all the filters test as true. (Much more about filters below)
An event might trigger in response to a collision, or to something dictated by a keyframe or expression (e.g. a bomb going off at a particular time). In the section below, we will using an animEvent (a bomb) to explain collision events further.
Using events and filters: an example
In the screenshot above, the top-left of the events tab lists all the events. The top-right section lists all the conditions that have to be met in order for the event to trigger and an object to be broken.
These conditions are called "filters", because they filter out unwanted objects from the large pool of available ones being simulated. Filters can test the properties of objects, or test something about the scene (e.g. the current frame number). It's in the filter stack that you specify what to break and when to break it.
The idea is the same as setting up rules in an email client to filter incoming mail, and then do something with it (e.g. move it to a different folder). By this analogy, the rigid bodies are the emails, and the action of breaking an object and modifying the resulting fragments is the move-to-folder.
Another way to think of the filter stack is like a stacked sieve. All the objects the simulator knows about go in the top, and only the ones that make it through the stack get broken.
The filters each evaluate to either true or false, and an object has to pass through all the filters (all true) to be considered for breaking. The system continually tries to match objects against the filters you've specified. It's easiest to think of it as running all the conditionals on all the objects on every frame, and only occasionally do all the criteria get met.
Going back to the first image, the object filter requires that a rigid body must come from the pCubeShape1 object. This doesn't say anything about whether the rigid body is unbroken, or a fragment that resulted from a previous break. (Fragments from previous breaks go back into the pool and are able to trigger events themselves). All objects carry around data with them, and it's the data filter that specifies that the piece of data named "fractureCount" (that's attached to a rigid body) must have the value zero, i.e. the rigid body must be unbroken, not a fragment. You can see the fractureCount listed on each object under the inputs tab. When a break occurs (we'll get to that) the fractureCount data of the fragment gets 1 added to it, meaning that a fragment will be unable to pass this data filter on subsequent frames; so this event won't ever break fragments. The time filter requires that the animation time be greater than or equal to 43, meaning the bomb won't go off until that time; for every frame less than 43 that filter evaluates to false, so again the event is prevented from triggering.
When one or more objects have passed the stack of filters, the script is run, which breaks each object. The fragments from an object will inherit all of the data it was carrying around. You can see from the MEL code below that the script requests that a particular rigid body be broken, and gets back a list of fragments from the system. It then loops over those fragments, adding 1 to the fractureCount and changing the color (so you can visually identify which event an object triggered). The last thing it does is run all the newly created fragments through a list of "modifiers".
If you look back at the first image, the bomb setup has one modifier by default, a "push modifier". Modifiers are also like the actions a mail client has (e.g. move message to folder), and will edit properties of the newly created fragments at the instant they are produced by the script. The push modifier pushes fragments in a particular direction by changing their velocity. You can add more than one of these modifiers, or delete it altogether. (See https://vimeo.com/10930640).
Modifiers is also the place where data attached to fragments can be changed, for example to cause a fragments to break with a different pattern the next time it triggers an event. The script is responsible for requesting that the fragments be run through the modifier list, so that you can intermix modifiers with effects more easily achieved through code.
Aside from the push modifier,other modifiers do things like randomization of attributes or rotation, or texture lookups, etc.For a detailed list of all modifiers, go here.
Incidentally, it's worth mentioning that there is no special "bomb" concept hardwired into the system; the bomb is just a templated event setup that gives you particular filters, modifiers and code by default.
After an object is broken and the fragments have been optionally modified in some way, they enter the pool of objects known to the simulator again, and are eligible for triggering events themselves. This process repeats on each frame.
Tutorials go here