# Ambient traffic close-orientation pass (r292)

## Captured result

I used the packaged Chrome viewer at Route 450, route distance 525, with the
camera debug-locked to each rendered traffic pose and the `trafficModel` debug
override set to each of the twelve density-eligible models. All screenshots use
BODY_A and tire variant B. The pose headings were all the same Route 450
heading, so the set checks model-frame orientation against one consistent road
frame rather than route-wide behavior.

The live debug records report `journeyDirection: 1`, `roadSurfaceSupported: true`,
and `frameUpZ` between `0.99999997` and `1.00000004` across all twelve
models. The largest absolute difference between `modelBaseZ` and sampled
`roadZ` is `0.0516` world units. The visible nose direction in the
side-view captures agrees with the Route 450 direction used by the viewer.
No BODY_A model was visibly inverted or reversed in this sample.

Individual Chrome captures are in [`traffic-orientation-r292.html`](../webgl-city/review/traffic-orientation-r292.html).
They show the active cars with plain white bodies and nearly black wheels. That
is a visible tire/material quality issue; these frames do not establish a
specific wheel-anchor error. The close set includes targeted PARCELVAN BODY_B and BODY_C captures. Both
report journeyDirection 1, road support true, and frameUpZ approximately
1.0; their visible nose direction also matches the Route 450 travel direction.
BODY_B/C for the other eleven models remain uninspected.

## Variant selection and capture scope

The current viewer loads only BODY_A during ordinary play. In
loadTrafficVehicleModels, the default variant list is exactly A; the body
chooser also returns A unless a debug URL explicitly sets trafficBodyVariant.
Therefore BODY_B/C for the other eleven models are not part of the viewer's
ordinary rendered path. The twelve BODY_A captures cover every model variant
the current normal viewer actually selects.

The known unusual PARCELVAN B/C transforms were still checked individually
because their recovered signed axes differ from A. Both diagnostic captures
remain upright when using their own manifest axes. Loading all twelve models
together with BODY_B stalled CDP evaluation, but that does not block the
ordinary A-only audit. I did not capture BODY_B/C for the other eleven models.

This describes viewer selection only. The retail executable's detail-slot to
BODY_A/B/C mapping is unresolved, so the captures do not establish which
variants the original game selects. If that mapping is recovered, or a
BODY_B/C defect is observed in a debug comparison, inspect those specific
models then.

No viewer transform or wheel-placement code was changed in this audit. The
PARCELVAN BODY_C image shows blocky black tire shapes, while BODY_A/B show
rounder silhouettes. The evidence does not establish whether this comes from
authored low-detail geometry, preview placement, or material response, so it
remains a visual issue rather than a proven transform defect.