Breaking Events - Determinism in Discrete & Continuous Event Simulation

Understanding Breaking Events is much easier if you’ve read the articles on Discrete Event Simulation and Determinism.

The Image above shows a schematic overview of how DES functions, and what we mean when we talk about a Breaking Event.

Progression of Time in Unity3D

Time in Unity3D progresses discretely. that means, the world is only updated (approx.) 50-60 times every simulated second (Fixed Update). In between those updates changes must be interpolated (we must make predictions on what happens using our own mathematical models). This frame-based handling of time is displayed in the image above using the blue arrows - each segment on the blue line represents a frame update.

What's' more is that Prespective DES supports Time Dilution (or Time Scaling). Effectively it means that in a single frame we can calculate more or less time progression than the actual duration of that frame (e.g. 0.04s in stead of the 0.02s it takes by default). Note the difference in frame size in the upper and lower blue lines

We’ve specifically chosen not to link this to the Unity3D Default Time Scaling option since that also seems to interfere with proper UX operations (e.g. handling button presses) - nor do we want to force a single timescale for the entire scene (it can greatly help testing to run part of your material handling process faster or slower than usual)

Interpolating what happens ‘in between 2 frames’

Run any material handling simulation long enough, and you will run into a situation where 2 virtual objects require (precise) interaction mid-way a simulation frame. As a simulation designer you should not need to learn different tooling for large- or small-space simulations or fast- or slow moving objects.

Material handling is distinctly continuous, requiring us to implement a system that would allow you continuous control in a discrete simulation regardless of simulation size and (relative) velocities:

All runtime motion is described by an interplay of motions over Paths or Splines. This means we know where all objects are- and are going at any moment in the simulation - even at any time between two frames.
Objects can have Thickness on these Splines, allowing us to simulate interaction and queueing behavior

Note that regulating motion using splines does not mean we cannot create complex motion (beyond moving up-and-down a predefined path). A Spline is a mathematical construct that can be interpolated to form Tensor Product Surfaces and shapes. Simply put, Using just 2 splines you can establish a 2D surface an object can move over, using 3 splines you can create a constrained 3D space you can move through - arguably, every spline you add, adds a motion dimension.

I dare argue, there isn’t a motion imaginable you cannot create using a so-called Motion Tensor

So how should you imagine inter-frame continuous interpolation? Its basically a graph plotting Time against the Percentual Spline Progression of a moving object (see continuous interaction map in the image above). if two lines intersect we know material interacts, and we can resolve accordingly.

Breaking Events - Leveraging Performance with Precision

Although DES has a focus on precision, performance is not ignored - enter the Breaking events. Breaking events allow you to determine if a recalculation of relevant objects in the simulation is necessary. They are easiest explained with a scenario such as displayed schematically in the figure above:

Imagine 2 boxes, B1 and B2 moving over a single path or belt. Both are initially moving with 1m/s in an arbitrary direction, Box B2 is in front, followed by box B1. At some point Box B2’s path is blocked and its velocity is now 0m/s. A collision with Box B1 is immanent, but breaking events determine how the simulation will progress.

To save performance all individual objects calculate how their motion would progress at the start of the frame (parallel - see the top graph under continuous interaction map in the image above). In the following processing phase - When a timed event triggers, or interaction with other material is detected - the simulation may determine a recalculation of objects in the simulation is required - Breaking Events are just that - if we trigger a breaking event all (relevant) simulation objects will recalculate their behavior going from that point forward. Triggering such an event is thus ‘costly’ - but can sometimes be omitted if no objects are near, or the enacted logic does not actually change the objects' behavior.

Note however that an omitted breaking event can actually break the correct simulation resolution - in the scenario in the image above a non-breaking event on the collision of the boxes will result in a so-called restitution error (material will start clipping with each other)