# L4RA instance transform audit · r115

## Question

The recent drive capture showed malformed building geometry, raising the
possibility that the placement rotation was transposed. This audit compares
the exported model placement with the world-space AABB stored alongside each
source instance.

## NFSU2 record interpretation

The local L4RA `0x34103` records use `u16 type_index` at `+0x18`, flags at
`+0x1a`, world position at `+0x20`, and the nine signed rotation values at
`+0x2c`, scaled by 8192. The index is local to the corresponding `0x34102`
table. This agrees with the clean-room OpenUG2 reader's
[`winst_decode_placement`](https://github.com/whoismept/OpenUG2/blob/main/src/world_instance.c)
implementation. A separate Most Wanted format write-up places its index at
`+0x3e`; that offset does not resolve the L4RA data and must not be copied into
this exporter.

The rotation values are kept in source memory order when written into the
glTF matrix. The viewer applies the matrix using the same component equations
as the object header transform. The render-time transposed alternative was
compared against the placement's stored world bounds before changing any
scene transforms.

## AABB comparison

For each L4RA placement, the first resident prototype found for its type key
was bounded from its local source vertices. Its eight bounds corners were
transformed by the record position and rotation, then compared with the
record's six stored AABB floats. This covers 48,223 placements for which a
prototype bound was available.

| Rotation interpretation | Median summed AABB error | 90th percentile | Samples within 0.1 m |
|---|---:|---:|---:|
| Source memory order, current renderer | 0.186 m | 4.170 m | 18,897 / 48,223 |
| Transposed | 1.774 m | 15.586 m | 9,052 / 48,223 |

This is strong evidence against transposing all scenery rotations. It is not a
proof for every instance: some type keys have multiple resident copies, and
the audit deliberately used the first prototype bound rather than reproducing
the full retail visibility and model-selection rules. Placement rotation is
therefore not the identified cause of the remaining city defects.

## Resident-copy comparison follow-up · r191

I compared every L4RA resident object grouped by its `0x134011` solid key,
using the same leading-`0x11` padding removal as the world exporter. Of 8,636
keys with valid vertex data, 1,794 have repeated resident objects (2,099
additional copies). For every repeated key, the normalized vertex/index data,
material slices, texture-slot records, and object-header transform are
identical. The apparent raw-byte differences come from different amounts of
leading filler, not different model geometry. This eliminates first-resident
selection as a cause of the L4RA building-placement defects; the stored
instance bounds cannot select a different shape because no alternate shape is
present for the same key in this stream. The remaining placement mismatch
needs another source, such as world-instance interpretation or scene/LOD
visibility data, rather than a different resident mesh copy.

## Current visual checkpoint

The complete-page Chrome capture at route 450, distance 525, is
[`207-r115-ready-route450.png`](../webgl-city/review/images/207-r115-ready-route450.png).
The page reached “City scene ready” and reported 90,091 nearby triangles and
832 routes. Four traffic bodies were rendered in the capture. The screenshot
shows source-textured road paint and nearby walls/vegetation; it does not
reproduce every city block or the user's reported overturned traffic, so the
overall WebGL export remains incomplete.