CADKEY Gen 2 Part 2: The Boundary Between Curves and Faces

· reverse-engineering, cad, binary-formats, brep

Part 1 established the geometry stream: Gen 2 PRT files are heterogeneous binary database streams, their wireframe entities use a shared header and little-endian geometry, 02 02 records are COEDGE half-edges with real 3D vertices, 02 05 records are piecewise cubic 3D coefficient splines, and plane filtering produces inspectable DXF output across the corpus. What remains undiscovered is the semantic bridge above those verified pieces: which FACE payload fields own which boundary curves, how the embedded ACIS-like data maps back to CADKEY record IDs, how the 0b 0a/0b 0d blocks encode raw NURBS surfaces, and what several remaining tail records actually do.

This is Part 2: not a victory lap, and not a claim that the format is finished. The wireframe geometry is usable. The ownership graph is not. Part 3 ships the headless conversion service →

The investigation changed shape

Part 1 treated the file as a sequence of geometry records. That was enough to extract 5,950 entities from the initial 28-file set and produce valid 2D and 3D DXF files. It was not enough to explain why a CADKEY solid contains separate FACE-like records, cubic curves, COEDGE records, and large blocks that look like embedded ACIS data.

The next phase required a different question:

Which records describe geometry, and which records describe ownership of that geometry?

That distinction matters. A curve can be decoded perfectly while its relationship to a face remains unknown. A linked-list pointer can be reciprocal and plane-local without being a parent-face reference. A byte sequence can resemble a knot vector without proving where the control points are.

Confirmed since Part 1

02 05 is a cubic coefficient spline

The most complete new decode is the variable-length 02 05 00 ff record. For record size S, the coefficient count is determined by:

N = (S - 152) / 48
segments = N / 2

Each segment contains twelve little-endian doubles:

x3 x2 x1 x0  y3 y2 y1 y0  z3 z2 z1 z0

That interpretation is independently supported by the CADKEY SDK’s CK_SPL_C3 allocation pattern. It is also testable: evaluating the coefficients reproduces every audited record’s header endpoints and all 19,000 adjacent segment joins in the structural corpus.

This is a real decode. It is not a NURBS surface evaluator, and it does not identify the owning FACE.

The 02 02, 02 04, and 02 05 families share a common header. The fields at +36 and +40 are previous/next IDs in plane-local linked components. They are not universally:

  • a curve reference;
  • a parent-face reference;
  • a patch index; or
  • a direct COEDGE loop pointer.

The corrected component traversal is useful precisely because it limits the claim. In the 54-file audit, no connected component mixed plane IDs. In toyclip, reciprocal links and shared IDs reveal a coherent plane-local database structure. That is strong evidence about organization, but not yet about B-rep ownership.

The old FACE interpretation was wrong

The earlier claim that FACE +36/+40 fields directly resolved to COEDGE or PATCH records was an offset error. The fields are common linked-list positions. The +32 patch-index interpretation is withdrawn as well.

The 02 04 payload itself is stable: subtype 2, fixed 220-byte records, a 0x000f0003 discriminator/value at +72, and eighteen following little-endian doubles. The meaning of those eighteen values is still an open experiment, not a format fact.

0b 12 looks like an embedded ACIS database

Toyclip contains 23 0b 12 0f ff chunks, each 15,372 bytes. The first begins with:

ACIS BinaryFile
Unknown
ACIS 4.0.1 NT

Readable type names recur across the chunks: body, lump, shell, face, loop, coedge, edge, vertex, curve, surface, nubs, intcurve, and fmesh.

This is the leading candidate for the missing ownership structure. It is not yet a decoded cross-reference table. Matching integer values between the ACIS payload and CADKEY records is not enough; the ACIS object schema and identity mapping still need to be established.

The SDK is the next instrument

The extracted CADKEY 98 SDK changes the investigation strategy. The objective is not to reproduce the ACIS kernel or treat its DLLs as a black-box source of magic geometry. The SDK documents the calls needed to observe the model at the boundary where CADKEY uses it.

The supplied TestSol sample documents a solid import lifecycle:

begin state
read SAT into opaque BT_SOLID handles
register each solid
end state

The same SDK exposes mesh generation with a surface-facet tolerance and an angular tolerance, returning per-face vertices, normals, polygon indices, and color. That is the high-value comparison point for this investigation: a documented tessellation result can be compared against the embedded fmesh material and against the verified CADKEY geometry without guessing the internal ACIS object layout.

The original runtime is working again

The investigation now has a working visual checkpoint. CADKEY 98 is running under Wine in the remote desktop with its bundled OpenGL runtime restored. The original PRT files open, wireframes render, and the shipped DXF CDE can export them. This matters because it closes the gap between byte-level extraction and the application that originally created the files.

CADKEY 98 displaying the loaded assembly as a colored wireframe

CADKEY 98 rendering the loaded assembly as a colored wireframe under Wine. The display is not being treated as format evidence; it is a runtime sanity check that the loaded geometry is visible in the original application path.

The runtime path is now:

PRT file
    → CADKEY loader and database
    → reference/display initialization
    → visible wireframe
    → DXF CDE export

The DXF export is the stronger artifact. For example, the native export of toyclip.prt contains sixteen 3DFACE entities, matching the sixteen unresolved TYPE15 records in the PRT. That count match is a candidate correspondence, not yet a proof; the next check is vertex-by-vertex comparison. The screenshot establishes a different fact: CADKEY itself can load and display the same database that the parser is decoding.

This also narrows the role of disassembly. Ghidra is reserved for questions the SDK does not answer: how CADKEY initializes the solid function table, how PRT data reaches the solid subsystem, and which transformations and tolerances feed the display/export path. It is not necessary to reverse-engineer every Boolean operation or rebuild ACIS itself.

The immediate deliverable is a minimal 32-bit CADKEY extension based on the SDK sample. It will first exercise SAT loading and registration, then mesh extraction. Until that harness runs, the SDK signatures are documented interfaces, not evidence that the embedded Gen 2 0b 12 blocks can be passed directly to the kernel.

The unresolved questions

1. Which FACE owns which boundary?

The FACE records expose eighteen doubles, plausibly arranged as six 3-vectors. Several interpretations have been tested: direct perimeter vertices, parameter frames, and transformed coordinates. The natural direct matches to same-plane spline endpoints are absent, and the obvious A/B matrix transforms do not produce a general sub-millimeter correspondence.

There are suggestive local cases. In toyclip, some spline records sit in components containing COEDGEs and FACE-like records, and their endpoints match neighboring COEDGE vertices. That supports possible boundary-curve participation. It does not prove that the FACE owns that spline, and it is not universal across the corpus.

The next useful test is not another isolated offset guess. It is a complete component-level comparison across files, with explicit negative results retained.

2. Where are the raw NURBS controls?

The paired 0b 0a and 0b 0d blocks contain delimiter patterns, tolerance-like values, and knot-like regions. Earlier guesses about a fixed 4×4 control grid, degrees, weights, and float offsets did not meet independent geometry checks.

The current parser’s --nurbs output is deliberately topology-derived: it chains COEDGE vertices into DXF SPLINE entities. That output is useful for inspection, but it is not raw surface evaluation.

3. How does ACIS identify CADKEY records?

The embedded ACIS vocabulary makes a compelling case that the ownership graph may already be present in the file. The remaining problem is identity: ACIS object IDs, CADKEY entity IDs, COEDGE IDs, FACE IDs, and cubic-curve IDs may use different namespaces or serialization rules.

The correct next step is to parse the ACIS object records structurally before comparing IDs. Correlation comes after schema recovery, not before.

4. What are the remaining tail records?

0b 00, 0b 01, 0b 02, 0b 0c, and 0b 0e appear to be index or directory structures, but their fields are not yet assigned. TYPE15 records also carry real coordinate triples whose purpose is unknown. The large render/display regions remain low priority: they are likely precomputed viewport artifacts rather than the authoritative model geometry.

What is safe to claim now

  • The Gen 2 stream can be parsed without CADKEY or Wine.
  • Entity geometry is little-endian and the shared header is characterized.
  • Type 1 is ARC1 construction geometry; type 2 is a 3D LINE.
  • 02 02 COEDGE vertices produce a real 3D wireframe.
  • 02 05 records decode as cubic 3D coefficient splines.
  • Plane IDs separate profile geometry from construction geometry.
  • DXF exports are inspectable in FreeCAD and other CAD tools.
  • FACE payload structure is known, but FACE semantics and ownership are not.
  • --nurbs output is topology-derived, not raw NURBS evaluation.

What is not safe to claim yet

  • That FACE vectors are polygon vertices.
  • That common prev/next fields are face or curve ownership references.
  • That 0b 0a/0b 0d control points, degrees, or weights have been decoded.
  • That matching integer values prove CADKEY↔ACIS object identity.
  • That the current spline DXF is a reconstructed solid or exact surface.

The next attack surface

The investigation now has a constrained target:

  1. Build a schema-aware parser for the embedded ACIS chunks.
  2. Index ACIS objects by type, local ID, and reference fields.
  3. Compare those references against CADKEY component membership only after the ACIS layout is stable.
  4. Decode FACE candidates with cross-file invariants, not a single toyclip fit.
  5. Validate every proposed boundary against endpoints, plane IDs, and independent geometry.

The file is no longer opaque. The remaining difficulty is not finding bytes that look geometric. It is proving ownership without turning correlation into fiction.

Reference material