Production campaign bridges
Implemented 15 September 2026. The corrected production bridge fixture passed 79/79 native checks at 13:19:08 UTC (15:19:08 Vienna) in Unity 6000.3.24f1: current report. The Windows build completed at 15:19:56 Vienna. Actual full-stage bridge races, rendered pictures and loading-cycle memory acceptance remain separate and pending.
The first native production fixture produced 56 passes and one failure; its unchanged report is preserved as initial 56/1 report. All six moving lane traversals had continuous legal support and no crash/recovery. The Jungle02 countdown stationary trial drifted laterally 1.999301m in 15 seconds, exceeding the original 1.25m limit. The subsequent bounded static-tire-hold correction and expanded native regression are detailed below. The older 103/103 surface fixture only tested a separately instantiated 40m prototype. The original campaign Wood sections were static road quads; this document does not reinterpret those previous traversals as moving-bridge evidence.
Actual integration
TrackRuntime.CreateSamples plans bridge spans on the same approximately 2.5m stations used by the production road. BuildRoad removes both static road and apron for the entire moving span and invokes CampaignBridgeBuilder. The main curved deck uses the existing road positions and eight width strips. Its generated MeshFilter and MeshCollider reference the same mesh under one kinematic MovingBridgeDeck. Timber edge fascia, longitudinal stringers, cross-members, posts, parapets, main cables and hangers move with that body. The road width remains 12m, with parapets outside it at ±6.35m.
- Jungle02 uses its existing .49–.53 Wood section: approximately 166m including approaches.
- Canyon02 uses its existing .50–.54 Wood section: approximately 176m including approaches.
- Each bridge end has an approximately 12.5m articulated approach, split into eight 1.5m-wide timber slabs. These are real kinematic rigidbodies, with identical visual dimensions and BoxCollider dimensions. The fixed end follows the original road and the moving end follows the predicted deck pose. The narrow slabs approximate the small changing torsion; their 30mm longitudinal lap prevents an open hinge gap. This approximation needs the native offset-lane test, not only a positional calculation.
- No per-frame MeshCollider cooking or vertex deformation is used. Only kinematic poses, slab dimensions and corresponding visual scales are updated. Generated meshes are registered with the existing
GeneratedWorldResourcesowner.
The production vertical scale is 0.8 of the prototype's 0.10m amplitude: ±0.08m at 0.16Hz. Roll is at most 0.35 of 1.2°, reduced further according to the curved deck's maximum local lateral extent. Its additional edge rise is bounded to approximately 0.05m, keeping the complete deck near ±0.13m vertical movement. The prototype's public defaults remain unchanged. Both approaches receive the same predicted pose before native simulation. ResetMotion resets the bridge and its approaches together; a newly loaded course starts at phase zero. Named save checkpoints lie outside these spans, and the existing resume setup starts the riders before their next required gate.
The local fictional gorge is carved only beneath the two moving spans through TrackRuntime.GroundHeight: 30m depth in Jungle02 and 46m in Canyon02, with 14m smooth approach fades and a lateral fade from 20–130m. It removes the former graded ground immediately beneath the bridge. This does not alter centreline coordinates or the Alpine DEM. Terrain rendering and nearby terrain collision sample the same ground function. Full-scene terrain/bridge transition verification remains separate from the road-only native fixture.
Existing AI rules already look 158m ahead for section speed limits and suppress melee in the current section and 45m ahead when AvoidMelee is true. Both Wood sections declare 45km/h and AvoidMelee=true; this implementation preserves them. Road grip coefficients, gate tolerance and recovery rules remain unchanged; the bounded stationary tire-force correction is described below. The measured moving support velocity also activates the existing recorded wood-creak layer. Actual eight-rider congestion and audio presentation remain player-run acceptance tasks.
Alps02 natural stone crossing
Alps02 receives a fixed masonry crossing only where the current road is naturally at least 4.8m above the unchanged DEM across lanes −6/0/+6m for at least 35m. The planner selects the longest suitable interval, capped at approximately 96m. The offline station survey selects 1849.915–1924.911m, with minimum clearance 5.018m across those three lanes. It samples the original compressed Schneeberg elevation data and the unchanged revision 3 centreline. The native planner's complete-width selection is authoritative and records the actual interval.
The existing road mesh and collision remain intact on this bridge. The apron is omitted, the pre-existing natural DEM is restored below it instead of filling it with the generic road embankment, and two masonry arch sides/soffits plus stone parapets give the crossing structure. Neither the route nor the DEM samples are rewritten. The planner returns no crossing if an edited route has no suitable natural hollow; it does not force one by altering elevation.
Physical revision and historical compatibility
Bridged campaign courses use ContentRevision = 1,300,000,000 + geometryRevision. Current Jungle02/Canyon02 therefore become 1,300,000,001, and Alps02 becomes 1,300,000,003. Other campaign courses retain the C2-bank namespace of 1,000,000,000 plus geometry revision. RoadBankProfile.GeometryRevision decodes either namespace; its bank construction/evaluation is otherwise unchanged. Edited-spline revisions and old authored-bake loading also receive the bridge namespace, so a formerly static custom route cannot retain a checkpoint/record revision after becoming a moving bridge. The source scenes were rebaked for the 15:19:56 Vienna Windows build; future source geometry edits still require another bake.
Historical definitions below the bridge namespace retain their former static road/ground path. The original Alps01 incident and its explicit old-bank positive control are unaffected.
Native verification entry
Run Rampage.Editor.CampaignBridgeVerification.Run serially through the root-owned Editor pipeline. It writes Docs/QA/campaign-bridge-verification.json and fails on missing/overlapping collision, unsupported transitions, absence of measured support motion, crashes, recoveries, missed gates or failed restoration.
The fixture constructs each actual production bridge and its actual road/shoulders in a private PhysicsScene. It checks shared render/collider meshes, dynamic support on both approaches and the deck, absence of static road underneath, declared AI restrictions, and deterministic motion reset. Three actual BikeController traversals use lanes 0/+3/−3m, one declared 45km/h initial velocity seed, and then only throttle/brake/steering commands. Two stationary trials span 15 seconds of bridge oscillation: countdown (DriveEnabled=false) and an active player holding Brake=1 without throttle. Another active-player trial holds the brake on the actual static inclined approach road. The original support and 1.25m lateral gates remain intact; stationary trials additionally require less than 0.25m planar displacement after settling. A separate Alps02 geometry check requires a fixed arch over a real natural hollow. The fixture does not simulate the default scene, access a player profile or reposition a rider during a measured trial.
Stationary slope defect and bounded correction
The failed trace kept contact=1, road=1 and airborne duration=0. Its approximately 0.12m/s sideways creep came from BikeController compensating gravity only longitudinally during countdown while transverse traction was entirely proportional to slip. Thus the lateral force needed to resist the road bank existed only while the bike kept sliding. Canyon02's milder geometry drifted 0.227m and did not reveal the same limit failure.
The correction acts only below 1m/s relative to the measured ground velocity, with throttle at most 0.05 and brake above 0.5. It blends into full static traction below 0.35m/s at full brake. The two-dimensional demand cancels tangential gravity and the measured relative slip through AddForce; the shared traction budget is bounded by both the available brake deceleration and grip times the gravity-induced normal load. It neither fixes world coordinates nor assigns Rigidbody velocity, cannot adhere to an arbitrarily steep slope, and works for active player braking as well as countdown. Above 3.6km/h the ordinary steering/drive/traction calculation remains unchanged. The former unbounded countdown-only longitudinal gravity compensation is removed.
Actual corrected native results
The 79/79 report contains six completed driving trials plus six stationary trials, with no crashes, recoveries, resets or missed gates. Every trial retained 100% legal road contact and support. Jungle's moving-deck countdown and active-player-brake trials each recorded maximum lateral error 0.011401m and maximum planar displacement 0.018828m. Canyon recorded 0.001254m lateral and 0.006488m planar. Active braking on the actual static sloping approach roads moved only 0.000004m in Jungle and 0.000077m in Canyon. Lateral error and displacement use different origins and are not interchangeable. The original 1.25m lane limit and the added 0.25m stationary displacement limit both passed. Native scene/catalog/global state was restored.
Regression after the controller correction also passed surface physics 103/103 at 13:19:17 UTC, bank verification 118/118 at 13:19:25 UTC, and campaign verification 95/95. These fixtures establish the recorded physics/geometry scope; they do not establish full-scene traffic behavior or visual quality.
Resource and revision source audit
Read-only source review found no new global object registry, event subscription, RenderTexture, texture allocation or per-frame mesh allocation in the bridge classes. WorldMesh.Emit registers every generated mesh with the surrounding GeneratedWorldResources; its HashSet deduplicates a mesh shared by renderer and collider. Destroying the generated course root releases those owned native meshes and all child deck/approach rigidbodies and colliders. A track rebuild disables the old generated root before deferred destruction, preventing an old bridge from participating in another frame. Materials come from the existing bounded shared material families and remain owned by that existing cache. This source ownership audit is not a runtime loading/unloading memory pass.
CampaignCatalog upgrades original and loaded authored routes, and CampaignStageSceneEntry applies the same physical namespace to edited-spline hashes. The bridge planner requires that namespace; explicit earlier definitions retain static geometry. The existing bank algorithm and geometry-only revision decoding remain intact. The latest native campaign and bank reports validate the corresponding revision/centreline contracts.
Required follow-up: actual full-scene Jungle02/Canyon02 runs solo and with seven opponents, native loading/unloading cycles, approach/ground alignment images, physical Xbox feel, sound and frame-time measurements. No native, visual or AAA pass is claimed by source compilation alone.
The visual portal-to-main-cable gap identified by the source review is now closed in source: both sides at both bridge ends have an approximately 12.5m continuation, attached to the existing fixed portal top and the exact moving main-cable endpoint. Each continuation reuses eight cylinder segments sharing one course-owned mesh, with sag bounded to 0.22m. LateUpdate follows the deck's interpolated rendered pose, keeping the visible connection together between physics ticks. Only visual transforms change; no new colliders, rigidbodies, per-frame meshes or collision cooking are introduced. Rendered bridge pictures and loading-cycle verification of this addition remain pending; the earlier 79/79 physics report does not constitute its visual acceptance.
Sources and editable assets
All bridge meshes are original metric geometry authored in Assets/Rampage/Runtime/World/CampaignBridgeBuilder.cs. They use existing free BridgeTimber, Bark, ChapterMetal and TuscanStone material families; no new download, external account or purchased asset is required. Texture provenance remains in Docs/THIRD-PARTY-NOTICES.md and the existing material manifests. The two collider forms are the generated curved timber mesh and explicit articulated timber boxes; imported high-poly source assets are not embedded.