How to Evaluate a Geometry Engine for Its Intended Task

“What is the best geometry engine?” is a tempting question. It becomes less useful when the required task is left unspecified.

An engine can be suitable for a particular query while unsuitable for a required editing workflow or exchange obligation. A visually convincing result can also conceal a failure that matters for manufacturing.

This note describes evaluation lessons for NeuroCAD’s research process. It does not announce a new engine benchmark or a ranking of commercial products.

Replace a winner with a set of obligations

Take a housing containing a thin passage near an outer wall. Different questions require different evidence.

Does the passage connect the intended openings? Is the remaining wall acceptable? Can the diameter be edited without losing references? Does the requested export preserve the required geometry?

A single successful operation would not answer all four.

Make awkward cases part of the input

A suite containing only well-separated, generously sized primitives would miss important boundary conditions.

Useful adversarial cases could include nearly touching regions, coincident references, narrow gaps, invalid parameters, and edits that remove a feature. The evaluator should report unsupported cases or failures explicitly.

The expected behavior must be defined before looking at a rendered result. Otherwise the test can drift toward accepting whatever the implementation happens to produce.

Use an oracle appropriate to the question

For a simple analytical case, an independently derived value may provide a useful reference. For a more complex construction, comparison might require several invariants and a second method with different failure modes.

Agreement between two implementations is informative, but shared assumptions can make them wrong together.

A result should therefore record what was checked, how it was checked, and what remains unresolved. Counting successful cases without describing their scope can conceal weak coverage.

Treat conversions as experiments of their own

Producing a mesh from a solid is not the same experiment as constructing that solid. Reconstructing surfaces from sampled geometry adds another set of obligations.

Conversion time, approximation behavior, topology, and downstream usability need their own checks. They should not disappear inside a general “supported” label.

The practical lesson is to evaluate an engine against a declared engineering use. For Universal Geometric Language (UGL) research, the value of multiple representations would depend on preserving meaning across those uses—not on making every evaluator appear equally capable.

Research note: These proposed workflows do not establish current NeuroCAD feature availability, performance, or engineering qualification.