docs(vehicle): fresh probe data — the writer is the physics sim, asset pipeline ruled out
Rebuilt and re-ran the vehicle probe workflow: - Control (no terrain) falls and settles (300 -> 78 cm). - Terrain rises (313 -> 545 cm) with body velocity pinned to 0 and zero overlaps. - Turning physics OFF at 3 s stops the rise, so the Chaos vehicle solver is teleporting the body (transform set directly, no velocity) - not an external SetActorLocation. - 0 wheels in both runs, so the missing wheels are not the trigger; the terrain is what flips fall to rise. Ruled out the asset pipeline with commandlets: the FBX, the imported SK_Vehicle_Sedan (476x228x144 cm), the physics asset (452x205x40) and Terrain_DEM (380x210 m) are all correct; the logged '1 cm bounds' is a stale component read, not a bad mesh. Next: bisect step 2 - a stock AWheeledVehiclePawn beside AGigLineVehicle in the terrain probe map.
This commit is contained in:
1 parent
66ca685059
commit
620cbe181c
2 files changed
+32
No files matched your search
@@ -680,3 +680,31 @@ A visual change needs **build → import → render**, never just a render: `ren
|
||||
- The hero facade rework (split out of 0.3.0) is **closed at "surface detail that reads at 45 m"**. Done and committed: carved inscription, stepped medallions, light motto band + proud surround (all three had been buried inside the parapet), and gold JIMMY KIMMEL LIVE banner lettering.
|
||||
- **Banner lettering is procedural, not ComfyUI.** `Tools/gen/generate_banner_texture.py` draws the exact title with Pillow + Liberation Sans Bold. An image model (Qwen-Image 2.1) would mangle a trademark string and is research-only, so for a _known_ string a font rasteriser is strictly better than txt2img. Reserve ComfyUI/Qwen for things that need a model, not for literal text.
|
||||
- **Deferred to 0.9.0 (owner's instruction):** volute capital depth, lattice grille depth, and the full realism pass (banded rustication, measured materials, texel density, LOD/collision). The 0.9.0 "Hero façade (6840)" item records the hand-off.
|
||||
|
||||
## 2026-11-10 — Vehicle launch: the asset pipeline is ruled out
|
||||
|
||||
Re-checked the three "asset is broken" suspects with commandlets and each is **correct**:
|
||||
|
||||
- `vehicle_skeletal.fbx` geometry is X −2.38..2.38 m (the full car, 296 verts), not degenerate.
|
||||
- Imported `SK_Vehicle_Sedan` bounds are **origin (0,0,72) extent (238,114,72) cm** — the correct 4.76 x 2.28 x 1.44 m car, so the import scale is fine.
|
||||
- `Terrain_DEM` bounds are 380 x 210 m with no degenerate/NaN scale, and its body setup reports no convex/box/sphere elements.
|
||||
|
||||
So the "1 cm bounds" logged in the vehicle diagnostic is a **stale runtime read of the component bounds**, not an asset defect — the skeletal mesh is fine and the symptom is the teleport writing the actor transform, not a bad mesh. The launch is a runtime (Chaos movement / map) problem, not an import or build one.
|
||||
|
||||
## 2026-11-10 — Vehicle launch: fresh probe data, the writer is the physics sim
|
||||
|
||||
Rebuilt and re-ran the `ue_vehicle_probe_map.py` workflow (after `chmod u+w` the read-only `.umap`s and `rm` the four stale `VehicleProbe*` maps — `delete_asset` leaves the `.umap` on disk so the tool's own fallback never fires):
|
||||
|
||||
| t | control (no terrain) | terrain |
|
||||
| ---- | ------------------------- | ------------------------------- |
|
||||
| 0.03 | Z 300 vZ 0 | Z 313 vZ 0 |
|
||||
| 1.50 | Z 306 vZ 0 | Z 442 vZ 0 |
|
||||
| 2.25 | Z 299 **vZ −242** (falls) | Z 545 **vZ 1** (jumps up) |
|
||||
| 3.0 | settles Z 78 | settles Z 545, then physics OFF |
|
||||
|
||||
- **Control falls and settles** (300 → 78 cm); **terrain rises** (313 → 545 cm) with the body velocity pinned to 0 throughout and `overlaps: 0 []`.
|
||||
- **Turning physics OFF at 3 s stops the rise**: `physics OFF at Z 545` → `after 1 s without physics, Z 545`. So the writer is the physics simulation (Chaos vehicle solver teleporting the body, transform set directly), **not** an external `SetActorLocation` — the "transform written directly" reads that way because the solver moves the body without a velocity.
|
||||
- **0 wheels in both runs** (control also has `setups=4 wheels=0`), so the missing wheels are not the trigger — control falls with 0 wheels too. The terrain is what flips fall → rise.
|
||||
- The `1 cm` bounds (`extent 1,1,1`) persist in the diagnostic and are a **stale component read**, not the mesh (the imported `SK_Vehicle_Sedan` bounds are the correct 476 × 228 × 144 cm).
|
||||
|
||||
Next: the bisect plan step 2 — spawn a **stock `AWheeledVehiclePawn`** with `SK_Vehicle_Sedan` beside `AGigLineVehicle` in the terrain probe map. If the stock pawn also rises, the asset + terrain interaction is at fault; if it settles, `AGigLineVehicle`'s setup (movement subclass, mass override, panel attachment) is.
|
||||
@@ -11,6 +11,8 @@ Actionable task list for this project. This file is the single, central place fo
|
||||
|
||||
## Toolchain — end-to-end asset check (done 2026-11-10)
|
||||
|
||||
> [!IMPORTANT] Plan for 0.3.1 before other patches
|
||||
|
||||
The chain that answers "does the asset look right in both the staging map and the game map" is now one command: `python3 Tools/review/e2e_asset_check.py`. It renders the Blender source, empties both maps, runs both builders, captures, judges with two models, and regenerates `Screenshots/README.md`. Last full run: **PASS on all six steps** (empty maps 9 s, demo build 10 s, review build 9 s, captures 80 s, judge 388 s).
|
||||
|
||||
- [x] Group the sixty tools by sandbox: `Tools/unreal/`, `Tools/blender/`, `Tools/review/`, `Tools/gen/`, `Tools/input/`, with the layout documented in `Tools/README.md`.
|
||||
@@ -133,6 +135,8 @@ Deferred rather than guessed. What a fresh session needs:
|
||||
|
||||
Two facts that matter more than the hypothesis list above: on `ReviewMap`'s flat floor the **same pawn falls correctly** (Z 200 -> 87, vZ -663), and in `DemoMap` it teleports upward at any height - including 25 m in the air - with the transform written directly (clamping velocity to zero every frame does not stop it) while the body reports a near-zero velocity. Disabling the movement component's tick changes nothing; there are zero overlaps; the body is genuinely dynamic (`profile=PhysicsActor`); `shadow`-style collision explanations were ruled out by staging the terrain with **collision disabled entirely** and seeing the pawn still rise.
|
||||
|
||||
**Fresh probe data (2026-11-10) — the writer is the physics sim, not an external setter.** Control (no terrain) falls and settles (300 → 78 cm); terrain rises (313 → 545 cm) with body velocity pinned to 0 and `overlaps: 0`. **Turning physics OFF at 3 s stops the rise** (`physics OFF at Z 545` → `after 1 s without physics, Z 545`), so the Chaos vehicle solver is teleporting the body (transform set directly, no velocity). Both runs have `setups=4 wheels=0`, so the missing wheels are not the trigger — control falls with 0 wheels too; the terrain is what flips fall → rise. The asset pipeline is ruled out (FBX, `SK_Vehicle_Sedan` import 476×228×144 cm, physics asset 452×205×40, `Terrain_DEM` 380×210 m all correct; the `1 cm` bounds is a stale component read). Next: bisect step 2 — a stock `AWheeledVehiclePawn` beside `AGigLineVehicle` in the terrain probe map.
|
||||
|
||||
### Tasks
|
||||
|
||||
- [D] Give `SK_Vehicle_Sedan` a physics asset whose single chassis body matches the car's box and is positioned below the shell, then confirm the pawn settles on the road instead of launching. **Deferred**: the chassis box, mass and gravity all measure correct, so this is not the shape of the body.
|
||||
|
||||
Reference in new issue
Block a user