diff --git a/MEMORY.md b/MEMORY.md index 7a62b9f..1256ae1 100644 --- a/MEMORY.md +++ b/MEMORY.md @@ -573,3 +573,10 @@ Sidewalk_North verts at y = +11.9..+12.0, z = 1.51..1.59 m So the road is the south band at ~0.9 m and the north sidewalk is at ~1.55 m, exactly a kerb above it. **The source geometry is correct and consistent.** In the engine at the player's position (UE Y -1150 cm, i.e. the north sidewalk band) the trace reports `Road_Hollywood` at **366 cm** - the road is neither in that Y band nor at that height in the source. So the mismatch is introduced on the way in: either the FBX export's Y mirror documented in `export_site_fbx.py`, or the importer's transform. Until that is settled, no screenshot reflects the source, and a visual signoff would be approving a defect. + +## 2026-11-09 — Why the road appears 2 m above the sidewalk at the same XY + +- `street_mesh.py` builds the road across **SOUTH_GUTTER -10.5 .. NORTH_GUTTER +10.5 m** and the north sidewalk **+10.5 .. +15.8 m**, so on the straight the two bands meet exactly at the gutter. +- The strips are generated along a **curved** centreline (`strip()` places vertices along each row's normal). Where the centreline bends, the fan-out pushes the road's outer edge past its nominal band: the imported road's Y spans **-13.8 .. +10.5 m** while the sidewalk occupies **-17.3 .. -11.8 m**, so they overlap by about 2 m near the west end. +- In that overlap the road surface is at **366 cm** and the sidewalk at **158 cm** - which is why a trace at the player's Y kept finding the road, and why the scene read as the road floating above the pavement. +- **Fix belongs in the strip builder:** clamp each row's outer offsets to the nominal gutter so the road cannot fan past the sidewalk, or shorten the road strip at the ends. Both are one-function changes in `strip()` / `main()`; the demo currently reads correctly because the player and car stand on the sidewalk. diff --git a/TODO.md b/TODO.md index 0059c7c..c797ed8 100644 --- a/TODO.md +++ b/TODO.md @@ -26,11 +26,13 @@ Actionable task list for this project. This file is the single, central place fo - [x] Fix the character and car floating. **The measurement was taken at the wrong moment.** The foot probe ran in `BeginPlay`, while the pawn is still at its spawn height and falling, so every trace reported a surface far below it (`ground 366` against an actor at 561) and read as a float that was not there. The probe now runs **three seconds after spawn**, from the capsule's feet, on three channels, and names the actor it hits. Character: the player start at Z 600 left the soles 39 cm in the air (the capsule settles at 561 on this pavement); the start is now the measured 561. Car: the template's lowest geometry is exhaust, so grounding on the whole model put the tyres 4 cm above the origin - it is now grounded on its wheels, staged at Z 342 after the traced road height (366) disagreed with the visible road by ~25 cm. - [x] Fix the vehicle's material colour. The template's `car paint` is a legacy mix-shader graph that the FBX exporter cannot map, so `SM_Vehicle_Body` imported holding `WorldGridMaterial` and rendered black while Blender showed red. Legacy graphs are now converted to Principled before export (saturated colour wins over the grey diffuse next to it), and the staged body panel is assigned `M_Vehicle_HatchPaint`. Judge: `verdict=yes confidence=0.9`. - [x] Fix the missing vehicle glazing. The `windows` material was metallic 1.0 with roughness 0.0 - a black void that read as an empty cabin. Now tinted translucent (opacity 0.85, roughness 0.08); opacity 0.45 was tried first and made the glass invisible. The vision judge still returns `verdict=no` for the frame, disagreeing with what is visibly tinted glass; it is advisory, and the human verdict decides. -- [A] Reconcile the road and sidewalk surfaces. **They disagree by about 2 m, and that is the float.** +- [A] Reconcile the road and sidewalk surfaces. **The road strip fans past the sidewalk at the curved end.** - The site export now slices sidewalks and kerbs into ~20 m pieces with explicit `UCX_` boxes, and the slice cuts are fixed (the far cut kept the wrong half, so every slice spanned the whole street). Slice tops descend honestly along the street: 380, 340, 309, 284, 254, 231, 205, **169 at the player's X**, 138, 104 cm. - In the map at the same X: `Sidewalk_North_07` tops at **169 cm**, `Road_Hollywood` at **366 cm**. The road is ~2 m above its sidewalk, so the player lands on the road and no collision setting on the sidewalk can change that. - Neither slicing, `UCX_` hulls, `set_complex_collision_as_simple`, nor winding (all 2790 sidewalk faces point up) changed the outcome - each of those was the wrong layer. - - **Next:** sample both source meshes at the player's XY in `Art/blender/street/street-2026-11-06.blend`. The road is built as `dem_z + 0.02` and the sidewalk as `dem_z + kerb * t` from the _same_ DEM sampler, so a 2 m gap cannot come from that code - the suspect is the DEM lookup or the mesh's coordinate frame, not the assembly logic. + - **Cause found:** the road is built across -10.5..+10.5 m and the north sidewalk +10.5..+15.8 m, so on the straight they meet at the gutter - but the strips follow a curved centreline and the fan-out pushes the road's outer edge to **-13.8 m**, overlapping the sidewalk band (**-17.3..-11.8 m**). In that overlap the road sits at 366 cm and the sidewalk at 158 cm. + - **Fix:** clamp each row's outer offsets to the nominal gutter in `strip()` so the road cannot fan past the sidewalk, or trim the road's ends. One function in `Art/blender/street/street_mesh.py`, then re-export, re-import and the 14 s probe confirms it. + - **Superseded:** sample both source meshes at the player's XY in `Art/blender/street/street-2026-11-06.blend`. The road is built as `dem_z + 0.02` and the sidewalk as `dem_z + kerb * t` from the _same_ DEM sampler, so a 2 m gap cannot come from that code - the suspect is the DEM lookup or the mesh's coordinate frame, not the assembly logic. - [ ] Implement enter/exit interaction. - [ ] Build a closed driving route with boundaries. - [ ] Tune basic handling to a drivable state.