Part API versus Solid API

ClassCAD has two APIs for modelling solids:

• The Part API builds a parametric model with a history of features.
• The Solid API works on solids directly, without a history.

Both need a part, made with api.v1.part.create. Solid API code runs inside a part as one feature, an EntityInjection. The two approaches are described in the blog article on CAD programming.

The examples call the API through @buerli.io/classcad, which returns results directly.

Part API

The Part API works like a history-based CAD system:

• You work with features, not solids. Every operation (a cylinder, an extrusion, a boolean) adds a feature to the part's history.
• The engine keeps track of which feature made which solid. Solids are results, not objects you handle; where needed, you reference them by index.

const flangeSolid1 = await api.v1.part.boolean({
  id: flange,
  type: 'UNION',
  target: baseCyl,
  tools: [upperCyl],
})

The call does not return a solid you can change: it adds a feature to the history.

Solid API

The Solid API runs in an EntityInjection feature, as code that makes geometry, without a history:

• You work with solids directly. Operations such as union, translation or extrusion return solids.
• A variable that holds a solid can be used again, as long as no operation has consumed it. keepTools: true keeps the tools of an operation.
• References to BRep elements (faces, edges) are not tracked automatically.

const part = await api.v1.part.create()
const ei = await api.v1.part.entityInjection({ id: part })

const basic = await api.v1.solid.box({ id: ei, width, height, length })
const subBox = await api.v1.solid.box({
  id: ei,
  width: width - 2 * thickness,
  height: height - thickness,
  length: length - 2 * thickness,
})
await api.v1.solid.translation({ id: ei, target: subBox, translation: [0, 0, -thickness] })
await api.v1.solid.subtraction({ id: ei, target: basic, tools: [subBox], keepTools: true })

With keepTools: true, subBox stays available after the subtraction.

Solids and the history

A feature produces solids, and later features can consume them. The engine tracks which solids are still available at each step. It copies solids internally, so that the rollback bar in Buerligons can move back through the history without computing every feature again from the start.

No operationMoveBefore in code

A history is evaluated from top to bottom, feature by feature. In Buerligons, inserting a feature in the middle of a part means moving the rollback bar there; the feature tree calls api.v1.part.operationMoveBefore for it.

In code you don't need it: write the new call at the place in your code where it belongs. If it consumes features or solids, later calls can no longer use them; pass the new feature in their targets or tools instead. Accessing a consumed solid throws an error. (Buerligons replaces such references itself.)

Use operationMoveBefore and the rollback bar only when you build your own CAD interface on ClassCAD, and talk to us first.

No feature modelling inside an EntityInjection

Code in an EntityInjection feature runs again whenever the feature has to be recalculated: after a global part expression changes, or after an earlier feature changes.

In the current version, EntityInjection features are not recalculated: their geometry behaves like an imported STEP model. Recalculation comes in a later version.

To use a solid made with the Part API inside the Solid API, call api.v1.solid.fromFeature first. It copies the solid, so the original feature stays available when the rollback bar moves back to it. An example: a perforated sheet whose base is built with the Part API, and whose holes are a pattern made with the Solid API, positioned along a sine curve before they are subtracted.

Which one

Part API models are fully parametric, like those of high-end CAD systems, though with fewer modelling features. They are what makes it possible to move parametric models between CAD systems, which is a long-term goal. The Solid API is for code that computes a model from parameters and builds it again from scratch when they change; without the bookkeeping of features it is also faster.

	Part API	Solid API
Approach	features in a history	solids, directly
An operation returns	a feature	a solid
Access to solids	by feature and index	direct
References	tracked automatically	not tracked
Selection in an interface	yes	partly

Start with the Part API for a structured, parametric part. Use the Solid API for a part made from code, without a history.