Events and filters
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".
