Part API versus Solid API

When developing with ClassCAD, you have two powerful APIs at your disposal:

• The Part API – ideal for building parametric, feature-based models.
• The Solid API – ideal for direct solid modeling or defining custom feature logic.

For new users, understanding how these two APIs differ – especially in how they handle solids and features – is crucial for building stable and flexible models. We see two philosophies in CAD programming: Code-as-geometry and feature-by feature API as described in our blog article [link] By providing SolidAPI in addition to the PartAPI, we bridge the gap between these two philosophies.

You will always need a part created with api.v1.part.create to add features with part API or add custom Solid Api code. To embed SolidAPI code in an part you need a special feature called EntityInjection.

---

📐 Part API – Feature-Based Modeling

The Part API follows a history-based modeling approach, similar to how parametric CAD systems work.

🧱 Key Concepts

• You work with features, not solids.
• Every operation (like cylinder, extrusion, boolean) adds a feature to the model's history tree.
• The engine automatically tracks which solids are created by which features.
• Solids are internal results, not directly exposed. But they can be referenced also using solid indices if needed.

✳️ Example

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

• This doesn’t just return a new solid — it creates a feature that will exist in the model history.
• You can’t directly manipulate the solid — instead, you operate at the feature level.

---

🧊 Solid API – Direct Solid Manipulation

The Solid API is embedded as a single features in a part and works as the Code-as-geometry without a history.

🧪 Key Concepts

• You work directly with solids.
• Operations like boolean, transform, or extrude return immediate solid geometry.
• There are api calls that can keep or discard solids using the keepTools flag.
• Useful for building custom operations or reusable feature logic
• Variables holding solids can easily be reused in subsequent operations, as long as they are not "consumed".
• Within Solid APi we do not support automatic referencing of brep elements.

Example

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

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

• Here, you can reuse subBox because of keepSolid: true.

---

🔄 Understanding Solids and Feature Dependencies

Why Part API Can Be Tricky

Using the Part API requires understanding how feature dependencies and solid lifecycles work:

• When you create a feature, it produces solids — but other operations can later consume that solid.
• To build reliable sequences, the systen tracks which solids are still available at each step.
• Internally the system copies the solid so that the feature/solid can be used in a later feature. It seesm to be an overhead creating all these copies, but it is absolutely necessary to efficiently implement the rollbackbar or a open feature in our interactive environment Bueligons.
• Moving backward through the history of a part is basically managing consumed flags and visiblity. Suppose the system would not copy these solids, then moving the rollback backward would result always in a highly inefficient and unnecessary recalculation of all features from the beginning up to the current feature! !

⏪ Coding in Part API: Do not use operationMoveBefore and Rollback Bar

In history based Cad systems, the model is evaluated top-down, feature-by-feature — like reading a script line-by-line. When inserting a new feature somewhere in a part in our Buerligons, you move the rollbackbar to the place in the feature list you want to add the feature. This is where partApi.operationMoveBefore comes into the game, it is called from the react componet for our feature tree.

There is NO need to use operationMoveBefore when coding because you can simply add the new code at the adequate line in your code! BUT make sure, when you add a feature somewhere in the middle of the history and you consume features/solids, then these are no longer available later und you need to replace them with the new feature in the targets/tools parameter. Please note that internally we handle this automatically within our Buerligons system and replace correct targets. The system throws a runtime exception when executing code that accesses a consumed solidt. Please try model a part in Buerligons, compare the code generated before and after adding a new feature in the middle using

res = @api.v1.script.generate({ id: yourPartId, type: "GENERATE_ALL" });

Coding in an entityInjection container API: Do not use feature-based modeling, clear or similar things

Custom scripts that run as a entity injection feature within an part execute automatically whenever the feature needs to be recalculated. This happens after changing globlal part expressions or when features earlier in the history are modified and thus malking all later features dirty.

IMPORTANT NOTE: In current version we do not support the recalculation of the entity injection features. This will be available in a later version. At the moment the coded objects in entity injection behave like a imported step model.

📊 Summary Table

For our users it is important to understand, where we position us in the CAD and Code CAD world. We think that the interactive modelling and coding is interchangeable. That is why we provide both Buerligons for interactive modelling and all the APIs to "DO IT IN CODE".

With these full fledged parametric objects we build parts like other high end modelers, however do do not support as many modelling features. Full fledged parametric objects are necessary for our long term vision to be able to convert "many" parametric models between high end CAD systems without loosing the parametrics. We are aware that such a conversion wont work by 100% in any case!

On the other hand, we provide with Solid Api the possibility write code in a similar way like our code based CAD competitors. So avoiding the overhead beeing able to edit/manage features individually. Instead they basically change simply parameters in code and recalculate everything from scratch.

Concept	Part API	Solid API
Modeling approach	Feature-based history	Direct/Solid modeling
Main object	Features	Solids
Output of operations	Feature	Solid
Access to solids	Feature and indices	Direct
Referencing	Yes, handled automatically	no
Interactive Selection	Yes	no

---

💬 For New Users

• ✅ Start with the Part API if you're building a structured, parametric part.
• ✅ Use Solid API if you just want to create a part from code or are building custom features.
• ⚠️ Be mindful of feature/solid dependencies: solids created by "earlier" may be consumed.
• 🧠 Use operationMoveBefore and rollbackbar only when you build a custom GUI for your CAD, and make sure you understand the model state at that point in the history. You might better contact us in this case.