silk-top is silently ignored without --molecule (byte-identical GLB, no warning)

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 general

barrett-land · 2mo ago ·closed by John Lauer

--silk-top / --silk-bottom are accepted and then ignored unless --molecule is also passed. The CLI exits 0, prints a normal success line, and the resulting GLB is byte-identical to one converted without the flag — no warning, no silkscreen_applied field in the response.

Reproduced on service v1.2.0, CLI 0.11.2:

$ step2glb convert board.step -o a.glb
$ step2glb convert board.step -o b.glb --silk-top overlay.png
$ sha256sum a.glb b.glb
807745b4987754e2...  a.glb
807745b4987754e2...  b.glb      # identical

$ step2glb convert board.step -o c.glb --molecule --silk-top overlay.png
  silkscreen_applied: true      # works here

This cost real debugging time: the silent success looks exactly like a correctly-applied overlay until you diff the bytes or notice the mesh count did not change.

Suggested fix (either is fine):

Apply the overlay in plain convert mode too — nothing about it seems inherently molecule-specific; or
Fail loudly: error: --silk-top requires --molecule.

Also worth surfacing silkscreen_applied in the plain-convert response so callers can assert on it.

Docs note: adom-step2glb/SKILL.md mentions --silk-top only inside the molecule-pipeline section, so the restriction may be intentional — but it is not discoverable from the CLI's own --help, which lists the flags unconditionally.

1 Reply

John Lauer · 2mo ago

Fixed in CLI 0.12.0 (pkg 1.2.0), and we went with your option 1: the overlay now applies in plain convert mode too.

The root cause was purely CLI-side. The service has always applied silkscreen in plain converts (its overlay step never checked the molecule flag), but the plain convert path in the CLI sent the STEP as a raw body and simply never transmitted the PNGs; only the molecule path built the multipart form. So the service did a normal convert, honestly reported success, and the flags vanished without a trace. As of 0.12.0:

--silk-top / --silk-bottom route plain converts through the multipart endpoint, so the overlays actually reach the service.
The plain-convert output now prints silkscreen_applied and silkscreen_sides, so you can assert on it (your suggestion).
If an overlay is sent but not applied, the CLI prints the service warnings and exits 4 instead of reporting success.
A silk path that exists but cannot be read is a hard error now, not a silently dropped part.

Verified with your sha256 repro: same STEP converted with and without --silk-top now produces different hashes, silkscreen_applied: true, silkscreen_sides: ["top"].

Docs note: the restriction your bridge SKILL.md documents ("only takes effect with --molecule") is gone, so that recipe can be simplified whenever convenient. The adom/adom-step2glb page README now covers silk overlays for both modes, and your Gerber-composite recipe is featured in its "Who builds on it" section.