CADKEY Gen 2 Part 4: The Presentation Boundary

A technically correct export can still produce a misleading picture.

The native CADKEY DXF export was valid. It opened in CAD tools, preserved the expected assembly structure, and carried the geometry out of the original runtime. But feeding that DXF directly into a browser viewer produced the wrong visual story: annotation geometry exploded across the viewport, inserted components were treated as if they were ordinary top-level entities, and the result no longer resembled the CADKEY view.

That was not a DXF failure. It was a presentation-boundary failure.

The DXF is an assembly, not a flat list

The toy-clamp export contains reusable CAD blocks and instances:

The model components live in CKCOLL... blocks. Dimension graphics live in GENDIM... blocks. The native CADKEY viewport knows which of those should be visible for a normal model view. A minimal browser parser does not.

The first interactive viewer expanded everything. That made the page technically busy and visually wrong. It was rendering CAD’s bookkeeping instead of presenting the part.

Add an explicit normalization step

The shipping pipeline now has a presentation stage:

PRT
  → native CADKEY DXF
  → normalized scene JSON
  → browser renderer

The normalizer resolves the CAD-specific structure before the browser sees it:

• expands BLOCK / INSERT instances;
• applies insertion transforms;
• preserves source layer and component identity;
• filters dimension blocks by default;
• keeps construction geometry separately controllable;
• emits only supported renderable geometry;
• records skipped entities and layer statistics.

The output is deliberately boring. That is a feature. The browser receives objects it can draw rather than a legacy CAD database it has to reverse-engineer a second time.

Toy clamp result

The default normalized toy-clamp scene contains:

807 renderable objects
16 GENDIM dimension inserts hidden
3 presentation layers

The normalized scene is available beside the native DXF as a comparison artifact:

• Normalized toy-clamp scene
• Native toy-clamp DXF

The DXF remains the engineering ground truth. The JSON is a presentation derivative with an explicit policy, not a replacement for the source export.

Why not manually rebuild the DXF?

Manual assembly would throw away useful structure and create a second, less trustworthy file. The correct approach is to preserve the native export and derive a web asset from it.

That gives the service two clean deliverables:

1. the native DXF for CAD inspection and downstream engineering work;
2. a normalized scene for browser presentation, previews, and review workflows.

The two artifacts can be compared, regenerated, and audited independently.

Where Blender fits

Blender or FreeCAD may still be useful later for mesh baking, solid presentation, and polished renders. They belong after normalization, not in place of it:

native DXF
  → normalized scene
  → optional mesh/GLB baking
  → web viewer

That keeps proprietary CAD runtime behavior out of the browser and prevents a presentation tool from becoming the format parser.

Shipping lesson

The first version proved conversion. The second proved that the output could be inspected. This version makes the inspection honest.

A legacy conversion service should not only produce a file that opens. It should produce a file that can be presented without confusing annotations, construction layers, and reusable CAD blocks for the model itself.

The boundary is now explicit:

CADKEY compatibility belongs in setup and conversion.
Presentation policy belongs in normalization.
The browser renders normalized geometry.

That is the difference between exporting data and shipping a usable result.