Collision events and filters
| Line 14: | Line 14: | ||
[[Image:Events_ui.png | blah]] | [[Image:Events_ui.png | blah]] | ||
| + | <br> | ||
| − | 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. | + | 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. <br> |
These conditionals 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. | These conditionals 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. | ||
Revision as of 02:18, 10 May 2012
Contents |
Collision Events
Definition
Collision events give you procedural control over what, when and how objects break.
Background
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, active/passive collision objects, and many more. Inside the simulator, all of these different objects are handled in the same way.
A collision event consists out of one or more filters and breaking happens when all the filters of an event satisfy. It might be easy to think of filters as conditionals, or if-statements. In other words, breaking 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). The discussion below uses animEvents as illustration.
In practice
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 conditionals 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.
