thumbnail CLI advertises GLB input that the service rejects

by adom

The Adom STEP engine: fully manage STEP files. Convert to color-preserving GLB, render thumbnails and vector outlines, laser-etch MPNs, create and edit STEP geometry, extract features, and run molecule mode. One name for the thin Rust CLI and the shared OCCT service. Formerly 'step2glb' + 'service-step2glb'.

Overview Files Skills Discover Packages Releases Dependencies Issues16 Breadcrumbs Pull Requests Activity

Closed bug report

Ray · 1mo ago ·closed by Ray

Environment: step2glb CLI 0.12.0; service 1.3.0 d76451638fdc9d0f3914b7c6d0038ea06aaaf925; Linux/WSL2.

step2glb thumbnail --help advertises input .step / .stp / .glb and --kind glb. Supplying a valid detailed GLB fails HTTP 400 with: GLB input is not supported in service-step2glb v0.4.0+ (cadquery-ocp 7.8.x's RWGltf_CafReader is incomplete). POST source .step instead.

Expected: advertised GLB rendering works, or capability-aware CLI help/local validation clearly identifies the unsupported format before upload. Telling users to send STEP does not preserve embedded board textures. A native glTF renderer can produce the desired image from the same valid GLB; our local workaround uses the wiki Babylon 9 renderer directly. No upstream implementation or PR is in progress here. Attached current CLI help reproduces the misleading promise.

step2glb-thumbnail-help.txt

1 Reply

Ray · 1mo ago

Fixed in step2glb 0.12.1, published as adom/adom-step2glb 1.2.3 (adom-inc/step2glb 4fc5e99).

thumbnail no longer advertises GLB. The help says STEP only and why (the shared service's OCCT build cannot read GLB; a textured GLB is already renderable as-is by a glTF viewer such as the wiki's). --kind glb is refused, and a GLB by extension or by glTF magic under any name is refused before upload, exit 2, with that pointer. The GLB rendering itself is not coming back on the service side: cadquery-ocp's RWGltf_CafReader is the blocker, and rendering a textured GLB is a glTF renderer's job, which is what your local Babylon workaround does; #10 is where that path gets a supported home.

Found on the way: step2glb thumbnail part.step was broken outright on 0.12.0. The service moved /thumbnail onto its job queue and answers 202 + job_id, and the CLI printed that JSON as an error. 0.12.1 polls the job and fetches the PNG; the service (f02d090) now puts the same X-Width/X-Pose/X-Src-Kind/X-Bbox-Mm/X-Duration-Ms headers on the job result so nothing is lost.

Also reconciled: the 0.12.0 on the wiki had been published from a clone that branched at 0.11.0 and never returned to GitHub, so it lacked --compress and the web-grade LOD twin while GitHub lacked the plain-mode silk overlays. Both are in 0.12.1; adom-inc/step2glb main is the source of truth again.

One thing to check on machines that had 0.12.0: an old ~/.local/bin/step2glb from an earlier installer shadows the /usr/local/bin one the package installs now. which step2glb should say /usr/local/bin; delete the ~/.local/bin copy if it does not.