QA Ticket Resolution Log 8 / 8 RESOLVED

The resolver row pointed at assets/ase/omt/dino.ASE — a mesh that happens to be named "dino" inside the objects.omt container (a level prop, not the character). The ground truth was already on disk: the Ghidra-derived decomp spec docs/decomp/C3DDino.md captures the class's InitObject verbatim:

(**(code **)(puVar1 + 0xd8))(s_HIWALK,   s_dinowalk_ase);
(**(code **)(this->vftable + 0xd8))(s_HISHRINK, s_dinoshrink_ASE);
(**(code **)(this->vftable + 0xd8))(s_HISTOP,  s_dinostop_ase);
(**(code **)(this->vftable + 0xf0))(s_dino_png, 0);

The class registers dinostop.ase (+walk/shrink anims) and loads dino.png — both already extracted from the original install. One ls confirmed they exist.

Both bus meshes ship in the original install; the resolver had picked the wrong one. Their ASE material blocks distinguish them instantly:

bus.ASE:      *BITMAP "D:\neutron\run\png\bus.png"        ← school bus
retrobus.ASE: *BITMAP "D:\Jimmy\busretro.bmp"             ← Retroland shuttle

docs/decomp/C3DBus.md settles it from the binary itself: C3DBus's lazy visual loader "registers HIDEFAULT → bus.ase, loads bus.png into texture slot 0".

The reporter's "level editor model" instinct was exactly right — the bound mesh's own material path betrays its origin as a 3D-items pickup asset, not a character:

fish2.ASE: *BITMAP "D:\Jimmy (ken)\3D Items (pick up)\bmp\fish3.bmp"

docs/decomp/C3DDarwinFish.md shows the class registering darwinwalk.ase / darwinshrink.ASE / darwinstop.ase and loading darwin.png — the same registration pattern as the dino (the two classes share their decompiled InitObject shape).

This one had two layers. First, the resolver had no per-tag row for "kitty", so it should have fallen to a generic pickup. But the engine logs showed no cat mesh ever loading — because 3PIC entities with an authored SpriteIndex > 0 take a separate billboard shortcut. Decoding what that index actually points at explained the mystery floating "?":

The original game never renders this marker — the kitty pickup (the level's rescue-the-cat objective) shows the cat itself. docs/decomp/C3DKitty.md confirms cat animations + cat.png.

Bug A (white quad): the resolver row hardcoded 0050_32x32d32.png — an image-file ordinal from an older interpretation of SpriteIndex. That file doesn't exist (texture load fails → white). The generated sprite-chunk map, built after the SpriteIndex = canvas-chunk-id discovery, already had the right answer:

{ "sprites.omt", 50, ".../0071_128x128d32.png" },  /* balloon */

Bug B (colors): a hex dump of a 3BAL record in Level2.gam revealed three unparsed per-instance float properties:

Red   ... 3f000000  = 0.5      (big-endian float)
Green ... 3dcccccd  = 0.1
Blue  ... 3f800000  = 1.0

docs/decomp/C3DBalloon.md (measured from the binary) documents exactly where they go: "Adjusted canvas/material color record set to (Red, Green, Blue, 0.8)". That's what makes each balloon a different color — the engine just wasn't reading them.

Same root cause as the balloons, but this time the wrong file existed — which is why it rendered a piggybank rather than white. The stale row referenced image file 0041_…png; cross-checking the generated chunk map showed file 0041 actually belongs to canvas chunk 160:

{ "sprites.omt", 160, ".../0041_128x128d16.png" },  /* piggybank  ← what the row pointed at */
{ "sprites.omt",  41, ".../0062_64x64d32.png"  },  /* cone       ← what chunk 41 really is  */

A file-ordinal ↔ chunk-id collision: for low ids the two numbering schemes coincide (which is why older sprite rows worked), and they diverge exactly where this ticket found bugs. A third stale row (3LEA, leaves) was caught and fixed in the same sweep before anyone reported it.

The hardest item — every layer of the asset pipeline checked out clean, one by one: the banner texture parses correctly from the level container; the exported GLB embeds it on the right faces (verified by decoding the mesh's triangles + materials directly); the GLB loader uploads one GL texture per material group; the placement draw path passes no overrides; culling is off. The data was provably perfect:

With the asset exonerated, the suspect had to be runtime state. A raw view/projection camera descriptor was crafted to frame the sign headless — it rendered textured cloth with no text. Dumping the banner primitive's UVs exposed the trick: the banner is two co-planar quads at identical depth — triangles 0–7 sample the blank-cloth band of the texture, triangles 8–15 (drawn second) sample the text band:

tri  0  cloth  v= [-0.55 -0.20 -0.54]      tri  8  TEXT  v= [-0.65 -1.00 -0.99]
tri  1  cloth  v= [-0.20 -0.22 -0.54]      tri  9  TEXT  v= [-0.67 -0.65 -0.99]
...                                         ...      (same positions, same depth)

That's a decal pattern that only works under Direct3D 7's default depth test, D3DCMP_LESSEQUAL — equal-depth fragments pass, so the later text layer wins. OpenGL defaults to GL_LESS — equal-depth fragments fail, so the text layer could never draw a single pixel. The engine had simply never set a depth function.

The engine runs two games (JNBG and its sequel JN vs JN), and the checkpoint visual was a single hard-coded row pointing at the sequel's clock sprite for both. But the QA export itself contained the answer: the JNBG .gam authors SpriteIndex 42 on every checkpoint, and chunk 42 in sprites.omt is a canvas named — literally — flag: