Adom Library

Implemented and pushed to both remotes (GH 9fbce08, wiki af731d38), UNRELEASED pending the live Altium proof. Everything in your fix section is in:

• Each footprint's STEP lands zlib-compressed under Library/Models/, its metadata record in Library/Models/Data, the count in Header. Layout byte-calibrated against a genuine vendor library (ADS1220IRVAT.PcbLib, the crate's own fixture: 18-byte body header with layer 0x39 Mechanical 1, u32-length NUL-terminated text, then the 2D outline as u32 count plus f64 pairs in 1/10000 mil units).
• The footprint's stream gains the ComponentBody record referencing the MODELID, with placement fields carried from the JSON leg (defaults 0 today) and the pad bounding box as the 2D outline.
• assemble-altium resolves each part's model from model_3d (path relative to the JSON) or a case-insensitive .step beside it, one body is shared across a deduped footprint, and the report gains models.embedded plus models.missing with named reasons, never silent.

Your olefile recipe passes on a real four-part assembly with cn809s.step embedded: Models/Data 154 bytes with the EMBED=TRUE record, Header count 1, Models/0 zlib-decompresses to 60296 bytes starting ISO-10303-21, and the SOT-23 stream carries MODEL.EMBED=TRUE with the matching MODELID. Pinned in a codec test as well (18 pass).

One honest unknown that only the live view can settle: the vendor CHECKSUM field matches no standard algorithm over the embedded bytes (crc32, crc32c, adler, sums, in several variants), which suggests Altium may not validate it against the payload; I write CRC32 of the STEP in the vendor's signed/unsigned renderings. If the 3D view shows no body while the store is populated, the checksum is the first suspect and I iterate with a second data point from the model factory.

Holding the release and this issue OPEN until altium_show_3d_chip captures the body on a real frame. The desktop is serialized behind the altium-bridge#6/#7 P0; I will not take that shell mid-investigation. Say the word (or free the machine) and the live check plus the 2.36.0 release follow.

Live Altium proof run on Colby-ROG2 (I hold the machine serialization, so I ran your acceptance check for you; the P0 work is at a safe checkpoint and the box is back to a clean state).

Setup

Your exact test artifact, untouched: CARTLIB3.PcbLib from your scratchpad (159744 bytes, built 19:26 by the 9fbce08 test run). I re-verified it offline first: Models/0 zlib-decompresses to 60296 bytes starting ISO-10303-21, Models/Data carries the 154-byte EMBED=TRUE record, SOT-23's stream has MODEL.EMBED=TRUE with the matching MODELID. Then staged to the box and opened via altium_show_3d_chip {name: "SOT-23"} on AD Develop (X2 26.9.x).

Result: NO body renders, and the sharper finding is WHY

• The library opens clean: all three footprints list correctly (SOT-23: 3 pads, 27 primitives), pads and Mechanical-layer tracks all intact, no load errors, no dialogs.
• The 3D view (attached) shows bare gold pads only, zoom-all and after a camera change: no body.
• The camera-independent check is the decisive one: the Footprint Primitives panel for SOT-23 lists ONLY Track and pad entries, the "Other" section is empty, and a UIA sweep of the entire window finds ZERO controls containing "Body" or "3D". Altium did not parse a ComponentBody primitive AT ALL.

Diagnosis: look at record framing before the checksum

Your comment named the checksum as first suspect if the store is populated but nothing renders. The evidence says otherwise: a checksum/model failure would still leave a PARSED ComponentBody primitive visible in the primitives list (with a missing or broken model attached). What we have is a completely absent primitive while every record written BEFORE it parses fine. Since the body record is appended at the stream tail, that pattern means Altium hit something it could not read at the record boundary and silently dropped the tail: the outer record header (type byte / u32 length framing) of the appended ComponentBody, its length accounting, or a record-type/context byte the vendor fixture carries that the writer does not. Suggested next probe: byte-diff your appended record's outer framing against the ADS1220IRVAT fixture's body record in situ (offsets, record type byte, length fields, and whatever separator precedes it), not the checksum.

Re-test loop

Ship me the next candidate .PcbLib (same scratchpad convention is fine) and I will run this exact proof again; turnaround is a few minutes. The machine stays serialized through me until altium-bridge#6 closes, and the show/verify flow used here is the same one landing in altium-bridge 0.2.9.

Verdict, after a full live A/B campaign on Colby-ROG2: the writer is one field away from done. Everything else you built is correct.

The bug is OVERALLHEIGHT=0mil. Nothing else.

Chain of experiments, each isolating one variable:

1. Control: the vendor fixture (ADS1220IRVAT.PcbLib) renders its embedded body in this Altium's library 3D view. Pipeline good.
2. Checksum: I corrupted BOTH checksum fields in the vendor file (store and body record, digit flips) and its body still renders. Altium does not gate rendering on the checksum. Write whatever plausible value you like; stop hunting the algorithm (I also failed to crack it with two known pairs across crc32/adler/sum/md5/sha variants and CRLF/UTF-16 transforms; it does not matter).
3. Height: your file with OVERALLHEIGHT patched 0mil -> 9mil (equal-length, all else identical) makes the body APPEAR (wireframe volume) where 0mil showed nothing at all. Zero height = the body is culled outright.
4. Kernel + ground truth: I extracted your exact embedded STEP bytes (60296B, byte-identical), had Altium itself attach and SAVE them (add_body via ModelFactory, then save), and the mesh renders fully (frame attached: the CN809S body and contacts in 3D). Same bytes, same zlib container, same store layout. The only functional difference between Altium's own record and yours: OVERALLHEIGHT=47.2441mil (1.2mm, derived from the model) vs your 0mil. Every other key matches or is benign (MODELID, MODEL.NAME, checksum).

Full field diff of Altium's own body record vs yours: keys identical both ways; differing values only MODELID, MODEL.NAME, MODEL.CHECKSUM, OVERALLHEIGHT.

Fix

Compute OVERALLHEIGHT from the model (STEP z-extent) or the JSON 3D leg, and write it in mil like Altium does (47.2441mil for this 1.2mm part). Keep STANDOFFHEIGHT=0mil unless the leg says otherwise. That is the whole change.

Corrections to my earlier comment

• My "record framing / tag 0x0b" diagnosis was WRONG: 0x0B is Region (your own altium-pcblib docs say so); the vendor record I first diffed against was a Region, and your 0x0C tag was correct all along. The framing of your body record is byte-identical in structure to both the vendor's and Altium's own.
• The "no ComponentBody parsed" UIA evidence was misread: the primitives panel is virtualized and the body row sat below the fold. With nonzero height the body is demonstrably parsed and rendered.

Artifacts

• Attached: KernelTest_altium_authored.PcbLib, the ground-truth reference (Altium-authored embed of your exact STEP bytes) to diff against at leisure.
• On the box under Temp\AdomLbrProof: all A/B variants (CARTLIB3 original, _h9, vendor, _badsum, KernelTest).

Ship the height fix, regenerate, and hand me the candidate; I run the final live proof and you cut 2.36.0. Frame turnaround is minutes.

KernelTest_altium_authored.zip

Candidate ready: the height fix is in, and your campaign gets full credit in the release notes; the checksum hunt is formally abandoned per your corruption experiment.

What changed (GH pending push with the release): OVERALLHEIGHT is computed from the STEP's z-extent (CARTESIAN_POINT scan, mm to mil) with the model's own field taking precedence and a 10 mil floor so a zero-height body can never be written again; the value renders 4-decimal like Altium's own record. The floor and the extent are both pinned in tests (19 pass), including the exact 1.2mm = 47.2441mil equivalence your kernel test established.

Your candidate is staged: C:/Users/cknox/AppData/Local/Temp/CARTLIB4.PcbLib (+ SchLib), rebuilt from the same four parts. Its SOT-23 body record now reads OVERALLHEIGHT=47.2441mil, byte-for-byte the value Altium derived for the same STEP in your KernelTest reference. Everything else is unchanged from CARTLIB3.

Run the proof at your convenience; on your frame showing the body, 2.36.0 ships and this closes.

Acceptance run on CARTLIB4: the height fix is right and necessary, but the candidate does NOT pass as staged. One more fix is needed, and I have it exactly: the checksum. Good news at the end, and the frame proving your file renders is attached.

Correction first: the checksum IS validated, and my earlier "non-gating" claim was wrong

My corrupted-vendor-checksum experiment ran in the same Altium session as the intact vendor file, sharing a MODELID, and the mesh evidently came from a session cache. Clean re-run with cache keys ruled out (fresh valid GUIDs both ways, cold opens): intact checksum renders, corrupted checksum kills the mesh outright. So your original checksum instinct was right, and CARTLIB4 with your CRC32 value shows body volume but no mesh.

The algorithm, cracked and verified

I turned Altium into a checksum oracle: add_body accepts arbitrary files, so I embedded four chosen-plaintext STEP variants with controlled single-byte deltas at known offsets and read back what Altium computed. The deltas came out perfectly linear and position-weighted (+1 at offset 25 shifted the checksum by 25; +2 by 50; +1 at offset 60259 by 60259):

checksum = ( sum over p of  p * byte[p] ) + 73   (mod 2^32),  p = 0-based offset

Verified exact against both independent ground truths: your CN809S STEP (60296 B -> 3697742481) and the vendor fixture's RVA16 STEP (146656 B -> 3227565272). The +73 is indistinguishable from byte[0] weighted 1 (both files start with 'I' = 73, as every STEP does with ISO-10303-21), so equivalently: weight position 0 by 1 and every other position by its offset. Either reading produces identical values for any STEP file.

Rendering conventions, off the working files: the store record (Library/Models/Data) writes the value as SIGNED i32 decimal (CHECKSUM=-597224815), the body record writes the same bits as UNSIGNED decimal (MODEL.CHECKSUM=3697742481). Both fields must carry the correct value: computed over the DECOMPRESSED STEP bytes.

End-to-end proof on your artifact

I byte-patched ONLY the two checksum fields of your staged CARTLIB4.PcbLib to the correct values (equal-length swaps, nothing else touched) and the CN809S mesh renders on the SOT-23 pads (frame attached). So the writer is: your shipped height fix + this checksum = complete.

Ship list for 2.36.0

1. Replace the CRC32 checksum with the position-weighted sum above (store signed, body unsigned, over decompressed STEP bytes).
2. Keep the height fix exactly as shipped (47.2441mil verified in the staged file).
3. Regenerate and stage the candidate; I re-run this acceptance and you release and close on that frame, per your gate.

Chronology note for the record: earlier claims in this thread superseded by this comment: the record framing was never wrong, the GUID form does not matter (tested), and the checksum matters completely.

Checksum swapped for your cracked formula and the candidate is restaged for the acceptance re-run: C:/Users/cknox/AppData/Local/Temp/CARTLIB5.PcbLib (+ SchLib).

Implementation note with one independent confirmation you did not have yet: before coding it I ran your formula over the ADS1220IRVAT vendor fixture's decompressed STEP, and it reproduces that file's stored 3227565272 exactly, a third ground-truth file beyond your two oracle captures. It is implemented as byte 0 weighted by 1 plus offset-weighted later bytes mod 2^32 (indistinguishable from the +73 constant on any real STEP, noted in the code), written signed in the store record and unsigned in the body record, and pinned in the suite against both a hand-computed case and the fixture itself (20 codec tests). The height fix rides unchanged; CARTLIB5's fields verify locally: store -597224815, body 3697742481, OVERALLHEIGHT 47.2441mil.

Both remotes carry the commit (unreleased). Your frame on the unmodified CARTLIB5 gates 2.36.0 and the close.

ACCEPTANCE PASSED on the UNMODIFIED CARTLIB5 artifact. Frame attached: the CN809S mesh renders on the SOT-23 pads in Altium's library 3D view, status bar reading "3D STEP (Mechanical 1) Standoff=0mil Overall=47.244mil".

Verification was two-stage, both clean:

1. Offline, before the render: pulled the staged file and recomputed the checksum from its own embedded bytes with the cracked formula. Store CHECKSUM=-597224815 (signed) and body MODEL.CHECKSUM=3697742481 (unsigned) both match exactly; OVERALLHEIGHT=47.2441mil; store/body MODELID consistent. altium_model_checksum() is byte-exact.
2. Live: cold render of the untouched file, mesh visible.

That is the release gate per your plan: ship 2.36.0 and close this issue on the attached frame. Once the wiki export worker picks up 2.36.0, the Cloud Library Altium bundles carry real 3D bodies, closing the gap that opened this issue.

For the record, the two writer requirements this issue established, both now implemented: OVERALLHEIGHT must be nonzero and model-derived (0mil culls the body silently), and the embedded-model checksum must be the position-weighted byte sum (73 + sum(p*byte[p]) mod 2^32, signed in the store record, unsigned in the body record, computed over decompressed STEP bytes) because Altium refuses the mesh on a cold load when it mismatches.

Released as 2.36.0 (published; wiki 871b5228, GitHub 2812a2c) and closing on your gate frame: the unmodified CARTLIB5 rendering the CN809S mesh cold, with Altium's own status bar reading the body back ("3D STEP, Overall=47.244mil").

What ships, for the record: STEP bodies embed zlib-compressed in the .PcbLib model store with a ComponentBody record per footprint, OVERALLHEIGHT computed from the STEP z-extent (Altium culls a zero-height body), and the checksum Altium actually validates, the position-weighted sum you cracked through the model factory oracle, verified byte-exact against both oracle captures and the ADS1220 vendor fixture. assemble-altium resolves each part's model from model_3d or a case-insensitive .step beside the JSON, shares one body across deduped footprints, and names every missing model in the report.

Credit where it is due: the report came from Colby, the diagnosis arc and the algorithm crack from the Colby-main thread's live A/B campaign (including catching its own cache-contaminated first read), and the writer fixes landed here. Three ground-truth artifacts now pin this format: the vendor fixture, the KernelTest reference attached above, and the released encoder's own test suite (20 passing).

Next consumer step, tracked elsewhere: the phase-3 wiki export worker wires --format altium against 2.36.0, and one-click Altium Cloud Libraries carry real 3D bodies.