question

There is no "default" collision avoidance mechanism in FlexSim. Collision avoidance is completely dependent on the context that the modeler builds into the model. There are several different mechanisms available. If you don't expressly use one of these mechanisms, then objects will freely run over each other. As everyone has said, events fire in the system independent of the 3D painting mechanism.

AGVs

When you use an AGV network, there are two different possible mechanisms for collision avoidance. The first, and default, mechanism is to simply use control point allocation to manage collision avoidance. This is technically not collision avoidance, but rather a much simpler allocation-based scheme. The idea is that, if any given control point on the network can only be "claimed" by one AGV at any given time, and the control points are spaced apart sufficiently, then AGVs will inherently never collide. This is essentially the way that "traditional" AGV systems work in real life (although modern AGV systems are more sophisticated). The way this works is that an AGV will allocate ahead to the next control point at the time when it "pre-arrives" at its current control point, i.e. the point at which it could still stop at its current control point if it fails to allocate ahead, as described by Mischa. An event fires at the pre-arrival time to allocate ahead, and if successful, the AGV continues to the next control point, otherwise the AGV decelerates to stop at its current control point and wait until it can allocate ahead.

The second AGV collision avoidance mechanism is to use accumulating AGV paths. This is used in addition to the control point allocation mechanism. When an AGV enters a path, if that path is accumulating, then the AGV will detect which AGV, if any, is in front of it on that path. Then it will do an analysis of the kinematic profile of the AGV in front, relative to its own kinematic profile, and detect a time, if any, at which the distance between the two AGVs will cross a proximity threshold. If it finds such a time, then it will create a "proximity stop" event on the behind AGV. When that event happens the AGV will go into a proximity stop state and will decelerate to stop until a "resume threshold" distance has been cleared between the two AGVs.

Travel Networks

Travel Networks (using network nodes) are our older travel system, and are much simpler than the AGV system. When a path on a travel network is set to accumulating, it just assumes a FIFO ordering and limits the rate with which travelers can exit the path, based on traveler size and speed. The 3D paint routine is used to update the locations of the travelers (a behind traveler will not be updated too close to an ahead traveler), but this is technically irrelevant to a statistical/simulation perspective. Statistically, the only thing that matters is the event for when a traveler enters a path and the event for when a traveler exits a path.

A*

The A* travel system uses a basic grid allocation mechanism, so again, it's not technically collision avoidance, but mutual exclusion through allocation. Each traveler allocates ahead to the next grid location before continuing to that grid location. For reasons of complexity, at this point there is no "pre-arrival" like in AGVs. In other words, A* travelers do not simulate acceleration/deceleration. They travel to a grid location they've allocated, and when they arrive at the grid location, they allocate ahead to the next grid location, and stop if they can't allocate ahead. For the purposes of speed and event-optimization, however, A* actually uses more of an "allocation scheduling" mechanism. There is technically no event that actually fires every time an A* traveler allocates ahead. Instead, when the A* traveler originally builds his path, the traveler "schedules" the allocations for that path. In other words, each grid point stores a "schedule" of allocations, which define which traveler is scheduling it, what time the allocation will start, and what time the allocation will end. Only when there are "collisions" in the allocations will the A* network create events to block travelers until they can allocate ahead.

TaskExecuter Collision Detection

You can also define a collision detection mechanism on each task executer individually. This is collision detection in the more traditional sense of the term. When enabled, the TaskExecuter will create collision detection events at regular intervals, will detect sphere-based collisions with other objects, and will fire triggers when collisions are detected. However, this mechanism is much more do-it-yourself, so it involves a lot more work on the modeler's part (and in my opinion could use some improvements). Even with improvements though, there are inherent problems with using a traditional collision detection mechanism in a discrete event paradigm, specifically in relation to run speed. Traditional collision detection, like that used in gaming, works well in gaming specifically because a game only needs to run in real-time. It can therefore use its update (repaint) loop to detect collisions. However, for many reasons already described by the other answers, discrete event simulation cannot rely on the 3D paint routine for simulation-critical logic. Thus it must create "tick" events to move the clock forward slightly and then redetect collisions. Unlike in gaming, discrete event simulation users expect their simulations to run hundreds or thousands of times faster than real time. Creating "ticks" for tiny time increments can create real problems when fast run speed is the goal. This is why most of FlexSim's "collision avoidance" mechanism are not "tick" based, and thus are not technically "collision avoidance" per se. They were designed this way specifically so that they will not hamper run speed.