Give the demo GLBs the up axis glTF defines - #1
Merged
Merged
Conversation
STEP and the OpenCASCADE kernel behind the CAD converter are Z-up; glTF
2.0 mandates +Y up. The converter emitted its tessellated geometry under
a bare `{"mesh": 0}` node with no transform, so every model in these
datasets reached the viewer lying on its back. Cascadia-App fixed the
converter in "Give converted CAD models the up axis glTF defines"; this
applies the same correction to the models already baked here.
The rotation is backfilled rather than re-converted. Cascadia-App's
scripts/fix-glb-up-axis.mjs rewrites only the GLB JSON chunk, leaving
the vertex buffer byte-for-byte alone, which matters more here than the
saved CPU: regenerating robot-arm needs the gitignored STEP sources and
a converter image that does not exist yet, and regenerating
freecad-demo means an hour of FreeCAD and KiCad that mints fresh UUIDs
every run — destroying the determinism the bundle exists to provide.
Leaving the accessors untouched also keeps cad_metadata's polygon counts
and bounding boxes true, and keeps the native part coordinates that let
the version-comparison overlay register two revisions without a
registration step.
robot-arm/glb is 79 plain files whose manifest records no hashes, so
they are rewritten in place. freecad-demo/files is content-addressed:
rewriting a blob changes its SHA-256, so each of the 120 GLB blobs is
renamed to its new hash, manifest.json's blob inventory is repointed,
and the 191 vault_files rows that referenced one — 120 blobs, shared by
dedup — get file_hash, content_sha256 and file_size updated. Nothing
else in the bundle carries a hash. vault_files.json is re-sorted with
the comparator bake-freecad-demo.ts uses, so a later re-bake still
compares clean.
Thumbnails are unchanged and were never wrong: they render through
OCC's own Z-up View_Iso(), which is why the geometry was correct in one
path and wrong only in the other.
Verified beyond the structural checks that all 616 blobs still hash to
their own names and every reference resolves: the PUC cart now stands
1164 mm tall in world Y with its wheels on the ground plane at Y = 0.01,
and the USV's 3 m is its X extent with the hull below the waterline.
Both upright, matching the readings that diagnosed the bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PGx2UWz6ZhqQu9KrT5zCWv
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
STEP and the OpenCASCADE kernel behind the CAD converter are Z-up; glTF 2.0 mandates +Y up. The converter emitted its geometry under a bare
{"mesh": 0}node with no transform, so every model in these datasets reached the viewer lying on its back. Cascadia-App fixed the converter in "Give converted CAD models the up axis glTF defines"; this applies the same correction to the models already baked here.Backfilled, not re-converted
scripts/fix-glb-up-axis.mjsfrom Cascadia-App rewrites only the GLB JSON chunk, leaving the vertex buffer byte-for-byte alone. That matters more here than the saved CPU:robot-arm/needs the gitignored STEP sources and a converter image that isn't published yet.freecad-demo/means an hour of FreeCAD + KiCad that mints fresh UUIDs every run, destroying the determinism the bundle exists to provide.Leaving the accessors untouched also keeps
cad_metadata's polygon counts and bounding boxes true, and keeps the native part coordinates the version-comparison overlay needs to register two revisions without a registration step.What changed
robot-arm/glb/freecad-demo/files/freecad-demo/manifest.jsonfreecad-demo/tables/vault_files.jsonfile_hash,content_sha256,file_sizeThe 191-vs-120 gap is blob dedup — several vault rows share a GLB. Nothing else in the bundle carries a hash.
vault_files.jsonis re-sorted with the comparatorbake-freecad-demo.tsuses, so a later re-bake still compares clean.Thumbnails are unchanged and were never wrong: they render through OCC's own Z-up
View_Iso(), which is why the geometry was correct in one path and wrong only in the other.Verification
All 616 blobs still hash to their own filenames; manifest ↔ disk agree both directions with sizes matching; every
vault_files.file_hashresolves; all 199 GLBs carry exactly the −90° X quaternion on a single reachable mesh node; the rewrite is idempotent. The workflow's own guard (79 GLB + 79 thumbnails, no STEP) holds.The decisive check was geometry rather than structure:
The cart's wheels land on the ground plane with its height in world Y, and the USV's "3 m" is its X extent with the hull below the waterline — both upright, matching the readings that diagnosed the bug.
Note for reviewers
The diff shows renames in
freecad-demo/files/at 91–99% similarity. That is the content-addressed store doing its job: the JSON chunk changed, so the name had to.🤖 Generated with Claude Code
https://claude.ai/code/session_01PGx2UWz6ZhqQu9KrT5zCWv