app

Adom Step2GLB - The Adom STEP Engine

Public Made by Adom

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'.

stepglbcadconverterocct3dthumbnailsstep-editingservice
Overview Files Skills Discover Packages Releases Dependencies Issues16 Breadcrumbs Pull Requests Activity
Closed general

/name-emboss strips XCAF colors from the returned STEP (silently), while chip-laser's /etch preserves them

John Lauer · 2mo ago ·closed by Ray

/name-emboss drops all XCAF color assignments from the STEP it returns. Found while generating hero art: the LQFP-100 library STEP converts with 3 materials normally, but after POST /name-emboss?name=STEP2GLB the returned named_step_b64, converted through our own /convert, yields 0 materials and the CLI prints its all-white warning. For the service whose headline differentiator is that colors survive, its own editing endpoint erasing them is a real footgun, and it is silent: the emboss response reports ok with no warning.

Repro:

  1. service-kicad model fetch Package_QFP.3dshapes/LQFP-100_14x14mm_P0.5mm.step
  2. POST /name-emboss?name=TEST&rot=180 with the STEP; decode named_step_b64
  3. step2glb convert embossed.step: materials: [] (original STEP: 3 materials)

Comparison: adom/adom-chip-laser's /etch on the same input returns a STEP that converts with 2 materials (body + light-grey inlay), so color-preserving text-into-die editing is achievable; we used it for the hero instead.

Ask: carry the source XCAF colors through the emboss (read with STEPCAFControl like /convert does), and at minimum surface a colors_preserved: false warning in the response until then. Service 1.2.1.

2 Replies

John Lauer · 1mo ago

Re-verified after the 1.3.0 change (service sha 18470db2, 'XCAF colours through /name-emboss'): not fixed yet, and the failure mode moved. Repro on the page's adom/lan7800 lan7800.step: /convert on the source yields 3 materials; POST /name-emboss?name=TEST7&rot=180 (job 5ad6a48000f76894) returns colors_in: 0, colors_out: 68, and converting the returned named_step_b64 yields exactly 1 material, a uniform light grey (0.80, 0.81, 0.83). So the emboss reader is not seeing the source's per-face colours at all (colors_in 0 on a file /convert reads 3 materials from; likely the reader is walking product labels rather than face/subshape colours, or the read happens without the XCAF colour mode the convert path uses), and it then paints every face a single default. That is arguably worse than the previous 0-materials output because the result looks coloured but is wrong. Suggest: read with STEPCAFControl_Reader in the same colour mode as step_to_gltf.py and copy colours per subshape (XCAFDoc_ColorSurf on faces) before the cut, and treat colors_in == 0 on a file whose /convert has materials as a hard error rather than proceeding. Leaving open.

This comment was deleted by its author · 1mo ago
Ray · 1mo ago

Fixed and live. Verified against the repro in this issue, on the LQFP-100 from Package_QFP.3dshapes.

Worth recording that this took two goes, because the first one is a trap anyone touching XCAF colours can fall into.

The original cause

occt_name_on_chip.py read with STEPControl_Reader and wrote with STEPControl_Writer. Those are the plain geometry classes and carry no colour document at all, so every colour was dropped on the floor. Now it reads and writes through STEPCAFControl and carries the source colours onto the result.

Two details that cost a round each:

  • Colours ride at face level. BRepAlgoAPI's history is face-based, so Modified() on a whole solid returns nothing and the colour lands on a label that resolves to no shape.
  • Faces resolve by TShape against the result. A face that survives the boolean is correctly reported as not-Modified, but the instance held from the source carries a different orientation and AddSubShape rejects it on that alone. 256 of 275 faces failed that way, silently.

Why the first fix did not fix this issue

It harvested colours only from labelled shapes. That works on libraries that colour per solid, and chip_74hc00.step is one of those with 30 coloured solids, so it verified clean and I called the issue closed too early.

The file in this report is the other kind. The LQFP-100 carries 1535 coloured faces and zero coloured solids, so the harvest returned nothing, only the mark grey was painted, and the result was exactly "reads zero source colours, then paints everything one flat grey". The live service reported colors_in: 0 on it.

The warning could not catch it either. It was written to fire when colours were found and then lost, not when none were found at all, so the case that most needed flagging was the one it stayed quiet on.

Both levels are harvested now, faces last so the more specific wins. This converges on what api/laser_etch.py already does, which had the right instinct written down: per-face colours too (some libraries colour faces).

Measured

Live service, service-step2glb 1.3.0 at d764516, this issue's own repro (POST /name-emboss, decode named_step_b64, step2glb convert):

LQFP-100 (face-coloured)      3 materials in  ->  4 out    was 3 in, 0 out
chip_74hc00 (solid-coloured)  5 materials in  ->  5 out    unchanged
emboss tally on LQFP-100      colors_in 1535, colors_out 1684

The extra material on the LQFP-100 is the mark itself, which now carries the same light grey laser_etch uses so an embossed STEP reads the same from either path.

The response also reports colors_in / colors_out now, and warns when the source holds colours but the harvest comes back empty, so this cannot go quiet again.

Closing, since it is verified on the reported file. Reopen if it misbehaves on a library I have not tried.

Log in to reply.