From fc1e8326648c1bdde35a827d6a3f0f69c50efa74 Mon Sep 17 00:00:00 2001 From: Zwitschi Date: Mon, 9 Nov 2026 22:25:49 +0100 Subject: [PATCH] docs(todo): remove the vehicle blocks that leaked into the hero facade section A shared heading string made one edit land in two sections, so the hero-facade task carried a copy of the vehicle's bisect evidence. The section is back to its own two steps. Also re-ran the gates on the tree as it stands after today's ground and placement work: Tools/ue_audit_scene.py 593 mesh actors, every mesh has a material, building X ranges as expected, no duplicate actor labels, 0 failures prettier --check all Markdown clean unittest 99 tests pass --- TODO.md | 63 --------------------------------------------------------- 1 file changed, 63 deletions(-) diff --git a/TODO.md b/TODO.md index b8ff70d..b8d1bc4 100644 --- a/TODO.md +++ b/TODO.md @@ -123,69 +123,6 @@ Deferred rather than guessed. What a fresh session needs: Split out of `0.3.0` on 2026-11-09 on the owner's instruction: the three hero-facade staging shots (`review-hero-facade-front`, `review-hero-facade-oblique`, `review-hero-portals`) were rejected as "rework needed to match reference", and that is asset work rather than vehicle work. -### Bisect result: the map, not the pawn - -The same pawn, unchanged, in two maps: - -``` -ReviewMap (flat 160 m floor): Z 200 -> 188 -> 174 -> 157 -> 87 vZ -208 -> -663 falls correctly -DemoMap, on the street: Z 486 -> 920 -> 1126 -> 1385 vZ oscillates ~0 teleports up -DemoMap, 60 m off the street: Z 291 -> 467 -> 920 -> 1343 vZ +1595 launches -DemoMap, 25 m above ground: Z 2496 -> 2664 -> 3068 -> 3434 vZ +1509 launches at once -``` - -**So the Chaos rig is fine and `DemoMap` is what breaks it** - at any height, anywhere in that map, and not by contact (25 m in the air launches immediately). The next comparison is between the two maps' world settings and level actors: `ReviewMap` was built by `Tools/ue_build_review_map.py`, `DemoMap` by `Tools/ue_build_demo_map.py`, and the difference that matters is in what one stages and the other does not. - -### The transform is written directly, not moved - -Zeroing the body's linear and angular velocity **every frame** for two seconds changes nothing: - -``` -t=0.25 Z=3220 vZ=0 t=0.75 Z=3683 vZ=0 t=1.25 Z=4197 vZ=0 -``` - -The actor keeps rising at ~1200 cm/s while its velocity is pinned to zero. **Something calls a transform setter on the vehicle every frame** - this is not a force, an impulse or a bad initial state, all of which the clamp would have removed. - -`Game/GigLine/Source/GigLine/*.cpp` contains exactly one direct transform write outside the character (`GigLineShotActor` moves its camera), so the writer is engine-side: the Chaos vehicle component driving `UpdatedComponent` from a vehicle state that was never created, or a skeletal-mesh transform update. - -### Map-content bisect: the terrain is involved - -Built `Tools/ue_vehicle_probe_map.py` (duplicates `ReviewMap`, optionally adds ONE demo mesh plus the pawn, saves as `VehicleProbe`) and ran it: - -``` -control (no extra mesh) Z 300 -> 297 over 1.25 s (resting on the review floor) -+ Terrain_DEM Z 300 -> 498 over 1.25 s (thrown upward) -``` - -So `Terrain_DEM` is enough to reproduce it in a map that otherwise works. Two fixes were then tried and **neither helped**: - -- `Tools/ue_clear_simple_collision.py` cleared the auto-generated convex hulls from all 76 site/street meshes (terrain had **1 convex element** over the whole 279 m) and set complex-as-simple - still rises. -- Setting the terrain component to `CollisionEnabled::QueryOnly` so traces still hit it but the physics solver ignores it - still rises. - -That means the ejection is not the convex hull and not the collision channel; the next probe is whether it is the _complex_ triangles (inverted winding pushing bodies out) - test by setting `Terrain_DEM` to **no collision at all** in the probe map and confirming the pawn falls. - -### Where it stands: deferred to its own session - -Three fixes were tried after the terrain bisect and **none changed the behaviour**: - -1. clearing the auto-generated convex hulls from all 76 site/street meshes; -2. setting the terrain component to `QueryOnly`; -3. staging the terrain in the probe map with **collision disabled entirely**. - -The pawn still rises in every case, so the fault is not the terrain's convex hull, not its collision channel, and not even its collision. The player is unaffected throughout - re-checked after each fix, and the character still stands on `Sidewalk_North_07` at 157 cm. - -Deferred rather than guessed. What a fresh session needs: - -- the probe workflow is in place: `Tools/ue_vehicle_probe_map.py` with `GIGLINE_PROBE_ASSET` and `GIGLINE_PROBE_NOCOLLISION`, `Tools/ue_clear_simple_collision.py` for the hull hygiene; -- the vehicle diagnostics are switches: `-probes`, `-profile`, `-novehmover`, plus the always-on velocity clamp, overlap list and velocity profile; -- the next question is _why a map carrying a 279 m static mesh changes a physics body's behaviour when that mesh has no collision at all_, which points at streaming, memory layout or the physics scene's broadphase rather than at collision authoring. - -### Bisect plan (kept for the next session) - -1. Spawn the same pawn in `ReviewMap` (flat 160 m floor, no slices, no UCX ground) and repeat the profile. Flies there too -> the asset/component is at fault. Settles there -> something in `DemoMap` (the UCS slabs, the terrain, or the world settings) drives it. -2. In parallel, spawn a stock `AWheeledVehiclePawn` with `SK_Vehicle_Sedan` and default settings in the same spot: if the stock pawn settles, the difference is in `AGigLineVehicle`'s setup (mass override, stability control, our movement subclass). -3. Only after the bisect: fix, then confirm `Wheels.Num() == 4`. - ### Tasks - [ ] Rebuild the El Capitan hero facade to match the reference photography: cornice depth, the banner proportions, window rhythm, and the three entry portals.