Urban Vitality P11 | UE5 Vehicle Motion: Body Clearance, Risk Response, and Collision Recovery

Urban Vitality · P11 · UE5 Logic Demo

P10 separated pedestrian motion into fixed steps, route advancement, crosswalk state, and tiered updates. P11 moves to the vehicle execution layer. It first examines how the source runtime connects wheel contact, suspension, tire forces, collision events, and presentation, then shows how our UE5 prototype validates following, yielding, trajectory risk, avoidance, damage, and recovery on one repeatable road fixture.

Analysis counterpart: Urban Vitality P4 | Vehicle Physics in an Open World (not yet published)

Introduction: validate vehicle decisions before driving feel

A vehicle demo often begins with a vehicle Actor, Chaos Vehicle, and a spline. Turning wheels and body motion prove that one Actor can move; they do not establish the runtime properties required by open-world traffic:

• whether queued vehicles preserve clearance between body envelopes;
• whether a red light, closed intersection, or pedestrian conflict constrains the correct vehicle;
• whether braking distance remains consistent with speed, reaction time, and deceleration;
• whether an avoidance maneuver still obeys longitudinal acceleration and following limits;
• whether damage, disablement, repair, and traffic capability remain connected;
• whether save and restore can continue an avoidance without replaying an impact or teleporting a vehicle.

The source vehicle runtime evaluates wheel queries, suspension, and tire forces at a fixed rate. Scene physics resolves world contact, rendering interpolates adjacent physical states, and collision facts continue into destruction and presentation. This chain establishes a more immediate requirement than a complete tire model: vehicle execution needs continuous, inspectable runtime facts.

P11 therefore does not treat “running in UE5” as evidence of production vehicle physics. Its acceptance layer uses neither Mass nor Chaos Vehicles. Deterministic kinematics and lightweight physical semantics are sufficient for testing the boundaries between motion decisions, traffic constraints, events, and persistence. Real wheel locations, Physics Assets, suspension travel, tire curves, center of mass, and inertia remain work for the presentation implementation and vehicle-asset calibration stages.

---

1. Source vehicle physics is not a closed component

Fixed-step timing belongs to the vehicle model

The source runtime evaluates wheel queries, suspension, tire forces, and rigid-body integration at a fixed frequency. A render frame consumes interpolation between adjacent physical states; it does not write the interpolated result back into physics.

At least three time domains are involved. The fixed step advances dynamics, scene physics resolves contact with the world, and the render frame provides visual smoothing. Placing all three responsibilities in one Tick would make frame-rate variation alter braking, suspension, and presentation at the same time.

A fixed step does not by itself imply bit-identical results across platforms. The source paths establish cadence and substep boundaries, not universal floating-point determinism. The UE5 prototype uses a fixed step to obtain repeatable logic acceptance and a stable save/restore boundary; it does not claim to have solved network determinism.

Throughout this article, repeatability has a specific meaning: the same data set and logical-step sequence produce the same observable decisions in the fixture—the same direct responder, response class, event order, and restorable in-progress maneuver. It does not promise bit-identical Chaos integration on different hardware. That stronger requirement would also need a deterministic numeric and replication strategy.

The render boundary is equally important. Interpolation may make a vehicle appear smooth between two accepted physical states, but the interpolated pose cannot become a second source of route progress. Otherwise an editor running at 120 FPS and a capture machine running at 30 FPS would feed different positions into stop-line and conflict calculations. P11 avoids that loop: logic advances on fixed steps, presentation reads completed state, and only measured execution feedback from a future authoritative rigid body may return through the defined handoff.

Wheel contact serves physics and presentation through different contracts

The traced source paths contain both ray and wheel-volume query branches. Query results feed logical suspension compression and visible wheel displacement, while the chassis retains adjacent physical states for render interpolation. A short loss of contact can also enter a decaying continuity path. That value may support grip or presentation feedback at confirmed call sites, but untraced consumers are not treated as established facts.

“Grounded” is therefore not one Boolean shared indiscriminately by every system:

State	Primary consumer	Valid approximation
Current query hit	Suspension support and rigid-body forces	Must come from an actual query
Continuous contact strength	Grip and traced presentation feedback	May decay across a brief miss
Visual wheel displacement	Wheel bones and body presentation	May compensate for asset offsets

P11 does not implement the complete per-wheel model. It preserves the same division of responsibility. Route kinematics owns continuous motion along the road. A lightweight physical layer owns surface, ground contact, grip, body offset, and damage semantics. The visible Actor only renders the published state.

One collision fact may have many consumers

After scene contact, the source runtime translates the same impact into body deformation, detachable parts, glass, lamps, audio, particles, camera feedback, and gameplay callbacks. Each consumer may have separate thresholds and cooldowns, but all must refer to the same contact event.

The prototype follows that rule. Damage cannot exist only as a material color, and a collision cannot exist only as a screen flash. An event needs at least a vehicle identity, sequence number, fixed-step index, impulse, and the damage state before and after application. Persistence can then determine whether an event has already occurred, and presentation does not need to reverse-query a physics object.

P11 does not copy the source per-wheel data model.

The source maintains query hits, contact normals, logical compression, visual displacement, previous-step compression, smoothed contact strength, wheel load, longitudinal and lateral slip, and ground material for each wheel. The chassis also stores adjacent physics states for rendering. Without a real vehicle asset, those fields would be driven by invented wheel positions, mass, and collision shapes. A passing test would not establish correct physics.

P11 retains the facts that must survive representation changes, persistence, and scheduling:

Retained by the prototype	Reason	Supplied later by a complete vehicle
VehicleId, lane, alpha, speed	Identity and traffic continuity	Not replaced
Body length, width, front/rear envelope	Following and stop-line calculations require them	Calibrated per asset
Target speed, acceleration, braking state	Risk response and queue propagation	Aligned with available tire grip
Surface, contact, grip, and body-pose semantics	Stable interface for presentation and damage	Produced by wheel queries and suspension
Healthy/Damaged/Disabled	Persistent damage across representations	Extended with part-level destruction
Impact/Repair events	Shared presentation input	Extended with normal, position, material, and part

The reduced model tests the vehicle–traffic contract before final assets are ready without treating a speed curve as complete vehicle physics. Chaos integration may replace ground-contact and body-feedback sources. VehicleId, route progress, the traffic Gate, and event sequences remain unchanged.

Kinematics, lightweight physics, and visible presentation execute in a fixed order.

Each P11 step evaluates the scenario phase and pedestrian conflicts, selects direct braking and avoidance targets, advances fleet kinematics and route recycling, updates lightweight physical semantics, and writes Damaged/Disabled capability back to the fleet. Visible transforms refresh only after those logic stages complete.

Because damage synchronization occurs after motion, a vehicle that becomes Disabled stops from the next step. Stopping within the same step would require the impact point to limit remaining displacement. The demo impact is a staged test event, not a continuous high-speed collision solve, so end-of-step synchronization is deliberate. It must not be described as substep collision response.

The order also defines which data a complete vehicle may replace. Chaos can own body transforms, wheel speed, suspension, and measured braking. It cannot rewrite VehicleId, route progress, or an emitted collision event from a presentation Tick. Conversely, traffic can provide target speed, Gate state, and hazard intent, but it cannot preserve a parallel “logically before the line” position after a near-field rigid body has crossed the stop line. Once the complete vehicle owns execution, its measured transform becomes authoritative and any deviation feeds back into traffic prediction.

P11 freezes three interface contracts:

Contract	Input	Output	Replaceable later
Traffic to execution	Route, Gate, target speed, risk response	Motion intent for this step	Controller and vehicle dynamics
Execution to traffic	Actual position, speed, damage, availability	New route progress and traffic capability	Data source, not semantics
Event to presentation	VehicleId, fixed step, impulse, before/after state	Audio, visual, and damage requests	Final assets and effects

The table is more than an architectural preference. It identifies the data that must survive a change of representation. Route progress cannot be inferred from a wheel animation after an Actor has been pooled. Damage cannot be inferred from the material currently assigned to a proxy. A collision effect cannot decide independently that an impact happened, because the logic event may already have been persisted and consumed. Each boundary has one direction for authority and a narrower direction for feedback.

This authority split prevents a common promotion failure. If the simplified traffic layer and the full physics vehicle both advance position, one VehicleId effectively controls two cars: one follows lane alpha and the other follows rigid-body contact. The discrepancy may stay visually small during ordinary driving, then surface at a stop line or after restore. P11 retains the logical route as intent and continuity data; once a near-field rigid body owns execution, its measured pose and speed close the loop. Demotion samples that state back into the cheaper representation.

Persistence and representation tiers both depend on these boundaries. Even if P12 demotes a nearby Actor to a cheap instance, traffic identity and emitted events cannot disappear with the component.

---

2. Road, fleet, and acceptance loop

A 300-meter road is enough to test execution boundaries

The fixture uses one 300-meter lane with a 14 m/s speed limit and an 11 m/s fleet target. The data set defines 12 stable VehicleIds: one leader and 11 followers. The leader starts at lane alpha = 0.50, vehicle centers are 13 meters apart, and the required bumper clearance is 7 meters.

A vehicle is not a point. The default passenger body is 4.8 meters long and 1.9 meters wide, with 2.4 meters in front of and behind the center. Following clearance is measured between bumpers:

Gap = LeaderCenter - LeaderRearExtent
    - (FollowerCenter + FollowerFrontExtent)

Initialization rejects any pair whose center distance is less than the minimum bumper gap plus the default vehicle length. This prevents both body overlap and an initially unsafe fleet from being handed to the following controller.

The 100-second loop is an acceptance fixture, not a cinematic timeline

One complete acceptance cycle lasts 100 seconds:

Phase	Duration	Contract under test
Cruise	3 s	Acceleration, target speed, queue advancement
Pedestrian Staging	1 s	Pedestrians approach while vehicles continue observing
Crosswalk Entry	3 s	Pedestrians enter; nearest upstream vehicle yields
Crosswalk Hold	3 s	Conflict space remains clear
Road Release	6 s	Vehicles resume through the queue
Secondary Event	72 s	Repeated surprise pedestrians, prediction, avoidance, one damage event
Recovery	12 s	Repair, speed recovery, preparation for the next cycle

Phases create repeatable conditions; they do not decide vehicle outcomes. Planned crossing closes the Gate of the vehicle that must stop. Surprise pedestrians are evaluated through trajectory prediction, which may select normal braking, emergency braking, or left/right avoidance. Every result still advances through the same fixed-step fleet path.

A vehicle reaching the end of the road is not moved immediately to the entrance. The runtime first confirms at least 13 meters of entrance space, then recycles at most one vehicle in that step. The relocation is recorded as route recycling rather than ordinary displacement, so acceptance statistics can distinguish a legal loop boundary from a teleport violation.

Data freezes the test conditions

Road length, speed limit, target speed, acceleration, braking, center spacing, crossing positions, conflict bounds, driver reaction time, and pedestrian cadence come from project JSON rather than level Blueprint constants. The principal values are:

Fixed step                  0.1 s
Target speed               11.0 m/s
Acceleration                2.8 m/s²
Normal braking              4.0 m/s²
Driver reaction time        0.6 s
Stopping safety margin      2.0 m
Planned crossing            lane alpha 0.60
Surprise conflict           lane alpha 0.78
Surprise pedestrian group   2 people
Crossing duration           6.0 s
Batch start interval        alternating 8.5 s / 9.7 s

The source field allows a maximum interval of 10 seconds, but event generation currently uses 0.8 of the interval range, producing 9.7 seconds for odd sequences. The 8.5- and 9.7-second values are start-to-start intervals between groups, not a delay after the previous group finishes. The article records observed runtime cadence rather than presenting the configured upper bound as the active value.

Keeping these values in data also makes the acceptance result reproducible. A reviewer can change target speed or reaction time and predict which derived values should move: stopping distance changes, the earliest TTC candidate may change, and an avoidance corridor may cease to be reachable. By contrast, vehicle identity, event ordering, and the meaning of a Gate should remain stable. The fixture therefore separates tunable driving parameters from structural runtime contracts.

The event interval illustrates why evaluated values matter more than field names. The nominal maximum suggests a ten-second cadence, while the implemented calculation produces a different start-to-start schedule. That schedule determines which fleet member reaches the conflict first. A source-grounded reconstruction has to follow the executed transformation.

Fleet configuration validates geometry before fixed-step execution begins.

ConfigureFleet creates 12 route states from leader alpha, center spacing, and vehicle count, then checks every pair in world space against MinimumGap + DefaultVehicleLength. Any pair below 11.8 meters clears the fleet and fails configuration. At the 13-meter initial spacing, a 4.8-meter body leaves 8.2 meters between bumpers, above the 7-meter requirement. Pairwise validation, rather than adjacent-index validation, also catches ordering faults or two IDs placed at the same location.

After configuration, lightweight physics creates one entry per VehicleId with zero steering input. A Fleet/Physical count or ID mismatch is reported as Missing during damage synchronization; array positions are never assumed to remain equivalent.

The fixed-step accumulator and the 100-second cycle are separate clocks.

Render Tick contributes real Delta to an accumulator. Vehicle logic runs only when the accumulator reaches the 0.1-second threshold. Status.ElapsedSeconds tracks total logical time, while CycleElapsedSeconds wraps at 100 seconds. Crossing the cycle boundary reconfigures the fleet, clears collision, repair, and avoidance-sequence flags, and increments CompletedCycleCount.

Candidate search does more than select the vehicle nearest to the crosswalk. Every non-disabled vehicle is tested against both pedestrians in the active batch. The earliest TTC selects the highest-risk candidate; near-equal TTC values prioritize emergency braking, normal braking, then left/right avoidance. A later avoidable candidate cannot overwrite an earlier hazard that only permits emergency braking.

The fixed-step order makes that selection inspectable. Phase transitions and pedestrian batches are committed before candidate evaluation. The selected direct responder and avoidance intent are then fixed for fleet advancement. Route recycling occurs only after movement, followed by physical semantics, damage synchronization, events, and visible presentation. Reordering those stages would change meaning. Recycling before risk evaluation could remove the vehicle that should respond; applying damage after presentation but before fleet synchronization could show a damaged color while the car still receives full target speed; rebuilding the visible proxy before restoring avoidance phase could produce a one-frame snap to lane center.

The fixture exposes those boundaries through separate counters rather than a single “test passed” flag. Candidate count, direct-braking VehicleId, avoiding VehicleId, route recycle count, collision count, repair count, maximum step distance, and teleport violations describe different failure classes. This matters during later asset integration: a visual regression must not be confused with a broken risk decision, and a correct response class must not hide a discontinuous transform.

Pedestrian timing, vehicle distance, and corridor availability produce repeatable coverage of both directions without changing the safety ordering. Exhaustively evaluating 12 vehicles against two pedestrians is negligible here. A city-scale system would first remove distant pairs through spatial indexing.

The 100-second reset exists only for repeated acceptance. A production city must not rebuild an entire fleet on that cadence; vehicles should continue along their current routes after a local event ends.

---

3. Replace center-point motion with body-envelope constraints

Following must measure bumper clearance

If following is based on centers, a short car and a long vehicle share the same threshold. Interpreting “7 meters between bumpers” as “7 meters between centers” leaves only 2.2 meters between two 4.8-meter vehicles. Their bodies may not overlap yet, but the required safety clearance has already failed. Maintaining a 7-meter bumper gap requires at least 11.8 meters between centers. P11 stores the body envelope in every vehicle state and uses bumper clearance throughout queue constraints.

Each fixed step computes an allowed speed from the leader, target speed, and Gate, then converges through acceleration or braking. Following limitation, normal braking, and emergency braking are recorded separately, allowing the HUD and tests to report the cause without inferring it from the image.

Stop-line clearance uses the front bumper as well:

FrontAlpha = CenterAlpha + FrontExtent / LaneLength
Clearance  = (StopLineAlpha - FrontAlpha) × LaneLength

“Stopped before the line” therefore means that the vehicle nose remains upstream, not merely that the Actor origin has not crossed.

The conversion is exact only for the current straight road, forward travel, and rectangular fixture. On a curve or under substantial yaw, body width contributes to the forward support point along the lane tangent. Production code should project an OBB onto that tangent instead of dividing a fixed half-length by total road length.

Closing a Gate constrains one direct responder

During the planned crossing, the runtime closes the Gate of the nearest vehicle upstream of the conflict point. Followers do not each read an independent pedestrian flag; they slow through the vehicle-following relation. The design keeps two facts separate: pedestrians directly constrain the vehicle nearest the conflict, while spacing propagates the effect through traffic.

Surprise events use the same rule. If trajectory evaluation selects braking, only the direct responder receives a closed Gate. Following constraints slow the vehicles behind it. Setting every vehicle speed to zero would remove the discrete propagation that the fixture needs to test, including emergency response to a suddenly disabled leader.

Emergency braking is the queue safety fallback

Acceptance includes an independent case in which the leader becomes disabled abruptly. With bTreatDisabledLeaderAsEmergency, a follower does not interpret the stopped leader as an ordinary slow target; it enters the emergency-braking path. This validates a fleet rule, not complete collision avoidance. It proves propagation from a known same-lane leader, but not lane cuts, occluded perception, or complex road geometry.

Per-step limits are derived from the leader/follower relation.

Vehicles on one route are ordered by progress. Each follower retains its own target speed, but its permitted movement also depends on the leader position, both body envelopes, and the minimum gap. Speed can converge only toward the permitted value; current momentum cannot carry the follower through the leader.

The implementation combines predicted leader displacement with available closing distance to produce an absolute speed limit for the follower. A distant stationary leader therefore does not force an immediate stop. This constraint currently applies only within one lane segment. Continuous following across segment boundaries remains unfinished.

PreviousState freezes leader selection, initial bumper clearance, and prediction input for the step so that behavior does not depend on raw array order. Vehicles are then processed explicitly front-to-back within each lane segment, allowing positional clamping to use the leader's completed position for the same step.

PredictedLeaderCenter =
  LeaderCenter + PredictedLeaderSpeed × DeltaTime

MaxFollowerCenter =
  PredictedLeaderCenter
  - LeaderRearExtent
  - FollowerFrontExtent
  - MinimumGap

GapConstrainedSpeed = max(
  0,
  (MaxFollowerCenter - FollowerCenter) / DeltaTime
)

TargetSpeed = min(
  GateAndDamageLimitedSpeed,
  GapConstrainedSpeed,
  FollowingPolicySpeed
)

Position clamping remains after speed integration. It reads the confirmed leader position for the current step, then rewrites follower speed, accumulated distance, and target speed from actual displacement. PositionClampedVehicleCount records every application. Automated coverage includes a moving leader, a distant stationary leader, a disabled leader, speed consistency after clamping, and normal cruise that does not rely indefinitely on clamping.

The clamp is a final safety bound, not the primary following model. Under ordinary conditions, predicted-leader speed and the gap-constrained target should keep the follower inside the valid range without repeated correction. A permanently rising clamp count would indicate that the speed policy and positional invariant disagree. P11 therefore checks both the safety outcome and whether normal cruise can proceed without depending on the fallback every step.

Processing front-to-back is essential after the prediction pass. PreviousState provides a stable input snapshot for leader choice and policy calculation, while the final positional bound uses the leader position already accepted in the current step. Using only previous-step positions would leave an avoidable lag in the bound. Updating vehicles in arbitrary storage order, on the other hand, would make the result depend on SoA compaction or ID insertion order. The two-stage design separates stable prediction input from ordered constraint enforcement.

The current guarantee remains deliberately narrow. It applies to vehicles that share one lane segment and a known front-to-back order. At a segment boundary, two vehicles may be topologically adjacent while their local alphas belong to different coordinate ranges. Extending the invariant requires route-distance continuity or a graph-aware predecessor relation; copying the same-alpha formula across segments would create a false guarantee. The article retains that limitation because the demo has not yet proved the stronger case.

LastGapMeters, bFollowingLimited, and bEmergencyBraking remain per-vehicle facts. The HUD exposes the current minimum bumper gap, while automation verifies that it does not cross the safety boundary. A center-only metric could pass even after visible body overlap.

Stop lines and hazards use the same body front.

Both the planned stop line and a surprise-pedestrian hazard need the vehicle's forward extent. P11 derives it from center alpha plus FrontExtent / LaneLength, avoiding one module using Actor Origin while another uses the bumper. A bus and a small car at the same center do not have the same remaining conflict clearance. Once a valid envelope is supplied per vehicle type, following Gap, stop-line Clearance, and Hazard Clearance all update through the same interface.

Current kinematics has no explicit jerk limit.

The fixed step changes speed under maximum acceleration and braking, but it does not separately limit jerk. Longitudinal acceleration may change within one logic step when the state moves from cruise to braking. That is sufficient for validating stopping distance and queue behavior in a box fixture. A complete vehicle needs powertrain response, brake build-up, or a comfort controller to constrain jerk, followed by recalibration of reaction time and safety margins.

The 2.8 m/s² acceleration and 4.0 m/s² braking values are fixture parameters, not a universal driving model. P11 proves that parameters enter one consistent calculation, not that their resulting feel is final.

---

4. Surprise pedestrians are resolved as space-time conflicts

Speed determines stopping distance

P11 splits required stopping distance into reaction and braking terms:

ReactionDistance = Speed × ReactionTime
BrakingDistance  = Speed² / (2 × Braking)
RequiredDistance = ReactionDistance + BrakingDistance + SafetyMargin

When a hazard remains ahead of the front bumper and available clearance is below the required distance, the vehicle must brake. Clearance below the pure braking distance marks emergency braking. The model is still a one-dimensional approximation without grade, tire temperature, wetness, or brake build-up, but unlike a fixed trigger distance it scales coherently with speed.

At the 11 m/s target, a 0.6-second reaction consumes 6.6 meters. Braking at 4 m/s² requires approximately 15.13 meters, and the 2-meter margin brings the total to about 23.73 meters. A fixed 10-meter trigger could stop too early at low speed and too late at high speed.

Clearance is measured from the bumper, not the center. A stationary vehicle or a hazard already behind it does not continue generating braking. Braking is clamped to a nonzero runtime floor to prevent division by zero, while data validation still requires a legal positive value. A runtime guard does not replace configuration admission.

Vehicle and pedestrian occupancy become time windows

A surprise pedestrian does not close the road simply by spawning. The runtime computes when the vehicle enters and leaves the longitudinal conflict range, then when the pedestrian enters and leaves the vehicle's lateral envelope. A predicted conflict exists only when those intervals overlap within the prediction horizon.

Inputs include the front-bumper progress, speed, length, and half-width of the vehicle; pedestrian longitudinal position, lateral offset, lateral speed, and radius; longitudinal and lateral margins; prediction horizon; reaction time; braking ability; and availability of left and right corridors.

The pedestrian radius currently expands only the lateral envelope: vehicle half-width + pedestrian radius + lateral margin. The longitudinal interval uses bumper-to-pedestrian clearance, vehicle length, and longitudinal margin without adding the pedestrian radius again. That choice matches this crossing fixture but is not a general 2D collision envelope. A production implementation must explicitly decide whether longitudinal projection also requires pedestrian shape.

If the vehicle can stop before the conflict, the response is Brake. If stopping distance is insufficient, predicted pedestrian position is compared with candidate offsets to the left and right. The runtime selects an available corridor with sufficient clearance and returns AvoidLeft or AvoidRight; if neither side qualifies, it returns EmergencyBrake. Selecting a corridor expresses intent, not proof that the vehicle can complete the lateral move in time.

The selection process therefore contains three different questions. First, do the vehicle and pedestrian occupy the conflict region at overlapping times? Second, can longitudinal braking keep the vehicle outside that region? Third, if braking cannot, is a lateral corridor both clear and reachable after reaction delay? Treating these as one trigger distance would erase the reason for a response and make later tuning unsafe. A larger pedestrian margin, for example, should expand the conflict interval; it should not silently redefine vehicle braking capability.

Earliest-TTC ordering also prevents a visually attractive but unsafe result. Suppose a later pedestrian leaves a wide corridor on the right while an earlier pedestrian blocks both sides. If selection simply prefers an available avoidance, the vehicle could begin the later maneuver and ignore the earlier unavoidable conflict. P11 first chooses the temporal hazard and only then selects its response. Severity is used as a tiebreaker for approximately equal TTC, not as permission for a later event to replace an earlier one.

Two uses of “emergency” remain distinct. Static hazard evaluation marks emergency braking when clearance is below pure braking distance. Trajectory evaluation returns Brake whenever stopping remains possible, tests avoidance only when stopping is no longer possible, and returns EmergencyBrake if both corridors fail. One describes braking intensity, the other chooses a response to a pedestrian trajectory. They cannot be collapsed into one distance threshold.

Avoidance receives no longitudinal privilege

Once avoidance begins, a four-second curve moves outward, holds, and returns. Maximum offset is 3.2 meters. Piecewise yaw reaches about 36 degrees and later counters by about 30 degrees to rejoin the lane. This observable fixture curve is not a tire-feasible steering trajectory.

An avoiding vehicle receives neither a longitudinal teleport nor an exemption from acceleration and following. The runtime restores its ordinary target speed, while actual advancement still passes through the fleet fixed step. If another vehicle remains ahead, the following ceiling still applies. Acceptance explicitly checks that adding lateral offset cannot elevate a queued vehicle to cruise speed.

Each avoidance belongs to one surprise-pedestrian sequence. A new batch cannot inherit the previous sequence's active state. After the lateral motion ends, the runtime waits until the vehicle recovers to 75 percent of target speed before incrementing the recovered-avoidance count. Completion of lateral motion and return to stable traffic are therefore separate observable states.

Conflict uses the intersection of vehicle and pedestrian occupancy intervals.

VehicleEntry = max(0, (Clearance - LongitudinalMargin) / Speed)
VehicleExit  = max(0, (Clearance + VehicleLength + LongitudinalMargin) / Speed)

Both occurrences of LongitudinalMargin refer to the same safety margin. For a moving pedestrian, the runtime computes the times at which the pedestrian reaches both sides of the vehicle's lateral envelope; the earlier time is entry and the later is exit. A stationary pedestrian already inside the envelope occupies the full prediction horizon. Entry is clamped above zero and exit below the horizon. An interval ending before zero, starting after the horizon, or producing an empty intersection is Clear.

Compared with matching two center-arrival times, interval overlap accounts for vehicle length and the time needed to traverse its full width. The current calculation still assumes constant longitudinal vehicle speed, constant lateral pedestrian speed, and a four-second horizon. Forced braking, pedestrian reversal, and curved roads need fuller trajectory sampling.

Left/right selection uses predicted pedestrian position.

A pedestrian currently on the left does not make the right corridor automatically safe. The runtime predicts lateral pedestrian position at conflict time, compares it with the ±3.2 m candidates, and prefers the larger clearance. Near-equal clearance uses pedestrian travel direction as a tiebreaker. If the preferred corridor is unavailable, the other side is tested before emergency braking.

Corridor availability is currently an input Boolean. It is not generated from nearby vehicles, curbs, barriers, or opposing traffic. P11 validates the selection protocol, not complete drivable-corridor search. Production integration must derive corridor clearance from road topology and nearby objects, including body width, turning radius, and curb boundaries.

Availability also passes a time-reachability gate:

AvailableLateralTime = max(0, TTC - ReactionTime)

ReachableOffset = FullOffset × clamp(
  AvailableLateralTime / TimeToFullOffset,
  0, 1
)

The response is AvoidLeft or AvoidRight only when the reachable offset has at least the lateral-envelope clearance from predicted pedestrian position and the corresponding corridor is available. Otherwise it falls back to EmergencyBrake. The current gate linearly estimates reachable offset from TimeToFullOffset, matching the fixture that reaches 3.2 meters in the first second and completes out-hold-return in four seconds. It validates admission for this curve, not numerical feasibility for full vehicle dynamics.

Corridor clearance alone is insufficient. A lane may be empty while the vehicle has only a fraction of a second before conflict. Granting the full 3.2-meter offset immediately would turn geometric possibility into a temporal teleport. P11 deducts reaction time and admits only the lateral travel available before TTC. Although tied to the fixture curve, the check prevents selection of an avoidance that the demo trajectory itself cannot reach.

Longitudinal and lateral constraints remain composed rather than substituted. Avoidance changes the lateral presentation path and steering intent. Fleet advancement still limits longitudinal speed through Gate, damage, predicted leader motion, and the 7-meter bumper requirement. This is why the demo can show a vehicle partway through a left maneuver while a newer hazard changes its immediate longitudinal response to emergency braking. The active lateral phase remains state; the new risk decision still constrains motion.

Early-out conditions are explicit. An inactive pedestrian, stationary vehicle, invalid horizon, or hazard already behind the longitudinal margin generates no response. A stationary pedestrian occupies the horizon only if it lies within the lateral envelope; a moving pedestrian enters and exits through the envelope boundaries. These Clear exits prevent a stationary person on a distant sidewalk from closing the road indefinitely.

The avoidance curve is an acceptance fixture, not a planning result.

The four-second action uses piecewise yaw and offset: steer outward, hold maximum offset, counter-steer, and return. It makes both phases visible in capture and permits automated key frames at fixed times. The curve is not integrated from wheelbase, steering limits, or tire grip, and lateral displacement is not a natural result of Chaos rigid-body forces. A later planner can publish target curvature for a vehicle controller while the P11 safety layer continues checking following limits, pedestrian clearance, and post-maneuver recovery.

Long-cycle evidence matters more than one key frame

Each surprise batch contains two pedestrians, alternates direction, crosses 13 meters in six seconds, and travels at about 2.17 m/s. The 72-second secondary-event phase reaches multiple vehicles under different arrival times. A single impact is injected only after the sixth actual AvoidLeft / AvoidRight intent, not merely after the sixth pedestrian batch appears.

The sequence rules out a false pass tied to one vehicle at one instant. Across the loop, a new vehicle must acquire risk response, the previous vehicle must return and recover, event sequences must re-arm independently, and repeated maneuvers must preserve fleet spacing.

---

5. Damage, events, and restore form one continuous state

Lightweight physics preserves semantics without claiming rigid-body fidelity

Each physical entry contains road surface, ground-query result, grip, body height/pitch/roll, steering yaw, and Healthy / Damaged / Disabled. These fields allow the fixture to verify that damage changes traffic capability. Current body feedback remains a deterministic approximation, not the natural outcome of per-wheel suspension and chassis integration.

The test impact is 5000 N·s. The lightweight damage model subtracts 1000 and scales the remainder to 40 damage points, moving the target from Healthy to Damaged without reaching Disabled. Damaged vehicles receive a lower target speed; disabled vehicles stop. The disabled-leader emergency-following test is a separate acceptance path and does not imply that the staged impact necessarily disables a vehicle.

Impact events retain before and after state

An impact changes more than an enum. The event queue records:

Sequence
FrameIndex
Type = Impact / Repair
VehicleId
ImpactImpulse
PreviousDamageState
ResultDamageState

Recovery iterates every non-healthy vehicle, emits an independent Repair event, and synchronizes restored speed and enablement back to the fleet. Presentation can consume impact, damage transition, and repair from the same event stream without watching private variables on each Actor.

The demo has not yet connected source-level contact normals, scrape duration, or multi-part destruction to visible assets. Its Impact/Repair event stores identity, sequence, fixed step, impulse, and damage transition. Directional presentation belongs to a separate request contract. Complete event payloads still need world position, normal, other entity, material, and affected part before final dents, broken glass, lamps, and scrape materials can be driven.

VehicleId carries lightweight damage back into the fleet.

ApplyImpact subtracts a 1000-unit no-damage threshold from impulse and divides the remainder by 100. Damage reaches Damaged at 25 and Disabled at 100. This deterministic acceptance curve contains no impact direction, vehicle mass, contact region, or energy-absorption structure.

SynchronizeFleetDamage maps Physical entries to Fleet vehicles by VehicleId. Healthy keeps ordinary target speed, Damaged reduces available target speed, and Disabled writes a disabled flag and stops. Damage enters motion policy rather than serving only as a visible color. Repair clears accumulated damage and state, then restores fleet eligibility through the same synchronization path.

Available speed is 1 - Damage / 200, clamped between 0.35 and 1.0, with Disabled forced to zero. Forty damage points produce 0.8 cruise capability. Under the current 100-point disable threshold, the drivable Damaged range corresponds to approximately 0.875–0.505, so the 0.35 floor does not currently activate; it protects future threshold or capability curves. This limit is applied before Gate, following, and driving policy, allowing one damaged vehicle to propagate a visible slow-traffic wave.

Physical state determines traffic capability; traffic does not infer damage from a red material. A future part-level destruction system can aggregate Driving Capability and write it into Fleet state without teaching signals, routes, or following code how a repair animation works.

Ground Contact and Surface metrics currently preserve interface semantics only.

Lightweight physics reports grounded vehicles, lost-grip vehicles, minimum surface grip, body-height offset, maximum tilt, and steering yaw. These stable interfaces make the future destination of budgeted world queries explicit and support HUD, snapshots, and presentation requests.

Without real wheel locations and complete wheel sweeps, deterministic fallback cannot prove behavior at curbs, slopes, airborne states, or single-wheel contact. “Lightweight physical semantics” describes the evidence; “suspension simulation complete” would exceed it.

A snapshot must include an avoidance already in progress

P11 snapshots contain fleet route, speed, following, and disablement; lightweight physical and damage state; scenario phase, cycle time, and statistics; event history and next sequence; collision and repair flags; active avoidance and direct-braking vehicles; avoidance direction, elapsed time, and pedestrian sequence; previous surprise sequence; and vehicles waiting to recover speed.

On restore, the fixed-step accumulator resets and visible proxies rebuild, while logical event sequence and in-progress actions continue. This prevents three generation-side faults: injecting the same collision again, snapping an avoiding vehicle to lane center, or assigning a reused sequence number to a new repair event.

ApplySnapshot validates before replacing state. Status, Fleet, and lightweight physics must already be configured; data must be legal; Fleet and Physical VehicleId sets must match without duplicates; active avoidance, direct braking, and recovery references must exist; event references must be valid; NextEventSequence must exceed the stored maximum; direction, elapsed time, and pedestrian batch must agree; and route progress must reproduce current world position within one centimeter. A failed check leaves current state unchanged.

Preflight acts as a transaction boundary. Validation reads the candidate snapshot and configured static context without progressively overwriting the live runtime. After every cross-table relation passes, the apply stage replaces phase, fleet, physical entries, events, and in-progress actions together. The runtime never enters a partial restore with saved route state beside current-session damage or avoidance.

Cross-table identity checks are particularly important because Fleet and Physical storage may have different ordering. Equal array lengths do not prove that row 5 in one table represents row 5 in the other. VehicleId is the join key, and duplicate or missing identities invalidate the snapshot. The same principle applies to an active avoidance reference: retaining elapsed time is meaningless if the referenced vehicle no longer exists in the restored fleet.

After preflight, phase, vehicles, physical state, events, and in-progress actions are applied together. The accumulator is cleared and visible proxies are rebuilt. Automation verifies that an invalid snapshot is rejected without mutation. The current check ensures only that the next sequence exceeds the existing maximum; it does not independently prove uniqueness among all stored event sequences.

Generation continuity is not consumption continuity. Saving the event array and next sequence prevents logical Impact/Repair generation from repeating. If audio, particles, or damage presentation owns LastConsumedEventSequence, that consumer cursor also needs persistence. It is not part of the present snapshot, so P11 proves generation-side continuity only.

The evidence stops at event generation. After restore, logic avoids recreating the same Impact and retains the next sequence number. A separate audio or particle consumer could still replay an old entry if its cursor restarted from zero. Production persistence must save that cursor, derive idempotent consumption from stable event IDs, or explicitly define which transient effects replay. P11 has not chosen among those policies.

Continuity needs a quantitative displacement check

Every step stores the previous vehicle position, computes maximum displacement, and derives an allowed limit from speed cap times step duration plus an acceleration term and small tolerance. A legal route-end recycle has a separate marker and is excluded from ordinary displacement. Other changes beyond the limit increment Teleport Violation.

This metric cannot prove that a curve looks natural. It can expose discrete jumps introduced by save/restore, route recycling, or state transitions before a detailed vehicle proxy hides them.

The first step after restore must retain side-effect memory.

Consider a save after the sixth avoidance and impact but before Recovery. Restoring only position would reset bCollisionInjected, allowing the same 5000 N·s impact to run again. Restoring events without NextEventSequence could make the new Repair reuse an existing number.

P11 saves collision/repair flags, the event array, next sequence, and the vehicle waiting for recovery. Active avoidance also saves elapsed time, direction, and crossing sequence. Rebuilt presentation resumes at the same lateral phase rather than restarting the four-second curve.

The snapshot is currently an in-memory structure copy with no disk version and no data-set version check. A production SaveGame must additionally handle deleted vehicle types, road changes, new event types, and migration of older damage data.

Route recycling and ordinary displacement are recorded separately.

The finite 300-meter fixture must return vehicles to the entrance during a 100-second cycle. Every recycle produces a structured record containing RelocationReason, pre-recycle Lane Alpha, expected and actual entrance position, entrance clearance, target error, and exemption eligibility. Exemption applies only if the vehicle reached the route end, entrance clearance satisfies initial spacing, target error is no more than one centimeter, and the reason is explicitly RouteRecycle.

Automation proves that an ordinary large displacement cannot receive the RouteRecycle exemption, but it has not yet injected such a displacement into the live loop and directly observed TeleportViolationCount increase. Loading a session intentionally returns to an earlier timeline; continuity checks examine the first step after load rather than classifying the load itself as an illegal teleport. A production road graph should use adjacent-zone portal handoff while retaining an equally explicit relocation reason.

---

6. Acceptance evidence and current limits

The HUD separates decision causes from execution results.

Speed alone cannot explain why a vehicle slowed. P11 separates scenario input, risk judgment, selected response, executing vehicle, fleet result, physical/event state, and continuity:

Layer	Representative fields	Purpose
Scenario input	Phase, Crosswalk Occupied, Surprise Sequence	Condition currently being generated
Risk judgment	Predicted Conflict, TTC, Clearance, Required Stopping Distance	Why a response is required
Response	Brake, EmergencyBrake, AvoidLeft/Right	Decision selected
Execution	Direct Braking Vehicle, Avoiding Vehicle, Lateral Offset	Vehicle carrying it out
Fleet result	Moving, Queued, Minimum Bumper Gap	Whether the queue remains safe
Physics/event	Damage, Collision Count, Repair Count	Whether events reached state
Continuity	Max Step Distance, Teleport Violations	Whether displacement remained continuous

Manual capture should show the pedestrian, stop line, responding vehicle, and HUD together. A vehicle moving sideways by itself cannot prove that trajectory conflict triggered the action or that followers retained clearance.

Key frames do not replace the complete cycle.

Capture support can record approximately 0.15, 1.0, 2.25, and 3.4 seconds after avoidance begins, covering initial steer, maximum offset, counter-steer, and near completion. These frames compare body position and pedestrian clearance but cannot show re-arming between batches, impact injection, or Recovery.

Acceptance therefore retains both key frames and a continuous 100-second recording. One checks a single trajectory; the other checks state across six avoidances, one impact, and one repair.

What to observe

The full cycle must establish all of the following:

1. Vehicles accelerate under fixed-step control without body overlap.
2. During planned crossing, the nearest upstream vehicle slows before its nose crosses the line and followers form a queue.
3. Vehicles resume in sequence after pedestrians leave rather than jumping to target speed together.
4. Secondary events expose conflict prediction, response type, conflict time, and the selected vehicle.
5. Avoidance produces lateral motion while longitudinal following remains active.
6. Completed and recovered avoidance counts continue rising across batches.
7. The sixth actual avoidance intent produces one damage event and Recovery produces one repair.
8. Saving, advancing, and restoring preserve position, speed, event sequence, and an in-progress avoidance.
9. After excluding explicit route recycling and session load, ordinary fixed steps keep TeleportViolationCount at zero.

Automated acceptance covers VehicleMotionArticle5Demo, map loading, and VehicleMotionSafetyEnvelope. A 100-second run additionally visits Cruise, planned yielding, repeated surprise avoidance, Collision, and Recovery. The frozen baseline passes these engineering and interactive checks.

The evidence is intentionally redundant. HUD values make the internal decision visible, screenshots preserve specific high-risk states, the continuous video proves temporal progression, and automation checks invariants that are difficult to judge by eye. No single source is sufficient. A screenshot can show a 3.2-meter offset without proving how it was selected. A unit test can prove response type without showing that the body rotates and returns. A video can look continuous while an event sequence silently repeats.

Finished vehicles should retain the same evidence structure. Asset review may add wheel compression, body roll, skid marks, and visible damage without removing the logical HUD or invariant tests. Visual quality must not make regressions in Gate ownership, bumper clearance, or event continuity harder to isolate.

What P11 proves

• Fixed-step acceleration, braking, and lane advancement remain continuous.
• Body envelopes participate in bumper-gap and stop-line calculations.
• Within one lane segment, predicted leader position, a 7-meter bumper gap, position clamping, and disabled-leader emergency braking hold.
• Pedestrian trajectories enter a time-window conflict test.
• Multiple conflicts are ordered by earliest TTC and severity, with explicit rules for Brake, EmergencyBrake, AvoidLeft, and AvoidRight.
• Avoidance admission checks reachable lateral clearance after reaction delay and falls back to emergency braking when time is insufficient.
• Lateral avoidance does not bypass longitudinal motion or following limits.
• Damage affects fleet capability and repair returns through an event.
• Snapshot preflight validates cross-table identity, active references, event upper bound, avoidance state, and route-position consistency.
• Legal route recycling has a structured reason and tolerance; ordinary large displacement cannot claim its exemption.

What P11 does not prove

• Correct Physics Assets, wheel positions, and collision shapes for production vehicles.
• Complete wheel queries, suspension, tire slip, weight transfer, or differential tuning.
• Multi-lane merging, overtaking, complex intersections, or high-speed opposing avoidance.
• Continuous following and bumper clamping across lane-segment boundaries.
• Pedestrian occlusion, sensor uncertainty, or multi-target trajectory prediction.
• Uniqueness among stored event sequences or restore of an independent presentation-consumer cursor.
• A live-loop injected illegal displacement that directly increments TeleportViolation.
• Physics budgets under variable frame rate, platform differences, or city-scale vehicle counts.
• Final quality of damage meshes, glass, lamps, audio, particles, or camera feedback.
• Smooth authority transfer between player driving and AI traffic control.

P11 is an acceptance environment for vehicle motion and risk response, not proof of completed vehicle physics. It fixes four boundaries before production assets arrive: identity and route continuity belong to the runtime; body envelopes participate in traffic safety; physics and presentation consume the same events; and a complete vehicle Actor is one high-cost execution representation of those facts.

Integrating Chaos replaces execution, not runtime identity.

A production vehicle can be introduced in three steps:

1. Replace the default 4.8 × 1.9 m envelope with per-vehicle data and revalidate following and stop-line clearance.
2. Let Chaos or the project vehicle model execute target speed, braking, and steering while logic continues publishing Route, Gate, and Hazard Intent.
3. Write measured collision, wheel-contact, and damage results back to lightweight physical state and the shared event stream.

The second step requires two-way validation. Logic may calculate that current clearance is sufficient, while a low-grip physical vehicle fails to stop. Logic cannot remain before the line while the visible rigid body passes it. Once a complete vehicle owns near-field execution, measured pose and speed are authoritative inputs to traffic prediction.

Feedback reports execution facts without transferring traffic identity to the physics Actor. A rigid body may report measured speed, route projection, contact state, and inability to satisfy requested deceleration. It cannot allocate a new VehicleId, decide that a red Gate is open, or emit a second logical Impact for contact already translated by the shared event bridge. The narrow handoff preserves one authority per fact.

Promotion has a corresponding admission problem. Before attaching a full vehicle, the runtime must establish an initial body pose, linear and angular velocity, wheel contact state, and a route projection consistent with the cheap representation. If the physical asset cannot be placed without penetrating the road or nearby vehicles, promotion should be delayed or corrected through an explicit transition path. Spawning it at the route center and allowing physics to “settle” would violate the same continuity contract that snapshots and route recycling currently test.

Demotion back to kinematics must sample current rigid-body pose, lane progress, speed, and damage rather than restarting from an old target transform. P11 already persists those fields but has not completed the real rigid-body handoff test.

Production-asset acceptance remains separate from logic tests.

Each vehicle type needs measured body envelope, wheelbase, wheel locations, static suspension compression, maximum travel, mass, center of mass, inertia, braking force, and grip by surface. Fixed cameras and inputs should then cover straight acceleration/deceleration, stop lines, following waves, curbs, slopes, single-wheel compression, wet braking, collision, and driving after repair.

Logic tests remain necessary because final assets can hide contract errors. A short mesh may avoid overlap even when center-gap logic is wrong. Forced animation may make a stop look smooth without fixing replayed events. The box fixture validates the contract; physics-ready vehicles validate execution quality. Neither replaces the other.

---

Conclusion: vehicle credibility begins with continuous boundaries

Source vehicle complexity comes from one chain of wheel queries, suspension, tire forces, scene contact, destruction, and presentation, all referring to the same vehicle. The UE5 logic demo selects the parts of that chain that depend on stable identity and time semantics: body clearance, stop lines, stopping distance, pedestrian conflict, avoidance, damage, events, and restore.

The prototype defines interfaces that later assets must preserve. Replacing a proxy with a Chaos vehicle must not recreate Route or VehicleId. Real suspension does not change the meaning of a traffic Gate. Collision effects consume existing events rather than deciding physical outcome again. Following limits, conflict priority, avoidance reachability, and snapshot cross-validation now hold at the logic layer; cross-segment clamping, event-sequence uniqueness, and production vehicle dynamics remain explicit future work.

P12 moves from one road and individual decisions to city scale: 300 logical vehicles and 2,048 logical pedestrians competing for a limited number of near-, mid-, far-, and hidden presentation slots while identity continues through pooling and distant aggregation.

AI Collaboration Notes

• AI contribution: Cross-referenced the P4 source analysis, P11 data set, body safety envelope, fixed-step fleet, lightweight physical layer, and demo Actor to document the relationships among vehicle center, body boundary, trajectory risk, events, and persistence.
• Human review still required: Driving feel, tire grip, suspension limits, visible collision quality, and audio/visual feedback require physics-ready assets, fixed-route capture, and parameter A/B review. They cannot be inferred from passing logic tests.
• Verification basis: Vehicle count, road scale, phase timing, speed, spacing, pedestrian cadence, and impulse come from project data; state boundaries come from the implemented C++. Logic fixes use ed6b7987 as the baseline, and article capture plus visible avoidance validation were updated through 682ed58a.
• Scope: This article records vehicle-motion boundaries verified by the UE5 logic prototype. It does not present lightweight body feedback as complete Chaos vehicle physics or the test avoidance curve as production trajectory planning.