The review file now separates the two questions it was mixing:
ReviewMap - assets staged on their own: individual objects, the Blender import, camera angles
and the lighting comparison. Nothing from the game map is involved.
DemoMap - the actual game map in development: street, buildings, player, vehicle in place.
One status table at the top covers both parts, with a Part column, and remains the only place
approval and issue notes are recorded. Between them sits the Blender-vs-UE comparison, which now
pairs ReviewMap captures as well as DemoMap ones, followed by the ReviewMap image grid and the
existing in-game shot sections.
Tools/ue_build_review_map.py also stages the LATEST vehicle assets (five systems plus the hatch
paint) and two new cameras - a three-quarter view of the car and a ground-level look at the
character's feet - so the staging map never drifts from what the Blender tools last produced.
Tools/render_screenshots.sh gained a second capture pass that renders ReviewMap into
Screenshots/review/, after the demo collection because that pass clears the engine's screenshot
folder.
Screenshots/README.md now opens with a single table that is the only place approval state and
issue notes live:
| # | Shot | Status | Note |
1 spawn-view, 2 street-level, 6 third-person, 7 third-person-front, 8 third-person-walk
carry 'character and car float'; the rest are blank.
Everything else that duplicated that information is gone: the per-shot Verified/Approved
bullets, the warning block at the top, the prose in the known-issues section, and the second
signoff table the comparison generator used to append. Every image is marked pending, because
every image changed and each needs a fresh approval.
The comparison section keeps its side-by-side image table and points at the status table for
approval, so there is one place to sign off and one place to read what is wrong.
Merged COMPARISON.md into the review README as a generated section between
<!-- blender-comparison:begin/end --> markers, so there is one place to look and one place
to sign off. Tools/build_comparison_md.py rewrites only that block - the hand-written
sections around it are untouched - and formats the file with prettier afterwards, because a
generated table is never byte-identical to prettier's output and the repo gates on
--check.
Run it after every capture or Blender render; it is the routine that keeps the page current
with new images rather than a one-off export.
Two tools for the comparison the review was missing.
- Tools/blender_screenshots.py renders out of a .blend: one image per mesh object, and
four turntable angles of the whole scene, framed from the scene's own bounds so adding
geometry never silently crops a shot. Output lands in Screenshots/blender/, beside the
in-game captures.
- Tools/build_comparison_md.py writes Screenshots/COMPARISON.md: a table with the in-game
capture and its Blender render side by side per row, then a signoff table with one row
per in-game screen. Unmatched shots show an em dash rather than disappearing, because a
missing Blender render is information too.
The first run already earns its keep: the Blender render of the owner's hot hatch is red
with clear glazing, while the in-game capture of the same asset is near-black, so the
material colour is being lost on import - visible in one glance in the new page.
zwitschi