Design Software History: From B-Rep Foundations to Cloud Kernels: Technical History of Parasolid, ACIS and Industrial Solid Modeling

From research to products

Academic B‑Rep foundations and the Cambridge lineage

Modern solid modeling in mechanical and architectural software rests on the intellectual bedrock of boundary representation (B‑Rep). In the late 1970s and early 1980s, Cambridge University researchers—most notably Ian Braid, working with Alan G. Bowyer, and later colleagues such as Charles Lang and Paul Turner—systematized the interplay between precise geometry and topology: faces bounded by edges, edges by vertices, and the links between curves, surfaces, and their trim. Their work on ROMULUS, emerging from Shape Data’s early activities in Cambridge, UK, framed practical algorithms for trimmed surfaces, topological consistency, and exactness where possible with analytic geometry and NURBS where necessary. This research-to-practice transition clarified essential modeling behaviors that product teams now take for granted: adjacency graphs, consistent orientation, and the separation of geometric evaluation from topological bookkeeping. It also established the importance of curves-on-surfaces (parametric trims) for robust intersection and detailing. From this lineage came a focus on error-bounded computation, leading to tolerant modeling under finite precision. The Cambridge milieu, linking academic rigor with industrial partners, created a template for commercial kernels: stable APIs, interoperable file formats, and carefully curated operator sets for Booleans, filleting, and shelling that could scale from prototypes to production.

• B‑Rep established a dual graph: topology for adjacency and geometry for evaluation.
• ROMULUS provided early commercial validation of trimmed surface workflows.
• Tolerances became first-class, recognizing floating‑point limitations from the outset.

From Romulus to Parasolid, and the parallel birth of ACIS

Out of Shape Data’s ROMULUS experience came Parasolid, introduced circa 1988 as a portable, licensable kernel optimized for manufacturable solids, robust Booleans, and reliable blends. Parasolid embedded the Cambridge B‑Rep DNA—analytic and spline surfaces, stable topology editing, and persistent identifiers—into a performant C library that OEMs could integrate. In parallel, in Boulder, Colorado, Richard “Dick” Sowar founded Spatial Technology (1986) and released ACIS around 1989–1990. ACIS delivered a modular, object‑oriented entity framework in C++, a clear contrast to Parasolid’s procedural style. Both kernels targeted the same industry pain: predictable solid operations and import/export stability across a rapidly diversifying CAD market. Licensing-friendly business models let CAD startups concentrate on features, not geometry algorithms. Through the late 1980s and early 1990s, Parasolid and ACIS accelerated a wave of mid-range and high-end applications because they solved the hardest low-level problems. The result was a virtuous cycle: more adopters reinforced their file formats (XT for Parasolid, SAT for ACIS), more models in the wild stressed the kernels, and each release hardened the algorithms, especially in surface–surface intersections, draft/offset, and filleting complexity that vendors needed to compete.

• Parasolid: C-based, high-performance operators with stable IDs and journaling.
• ACIS: C++ entities, extensible operators, and fine-grained integration points.
• Both: NURBS support, trimmed faces, and industrial Booleans.

Ownership and stewardship

Corporate lineages, governance choices, and long-term stability

Commercial stewardship shaped trust. Parasolid moved from Shape Data to Unigraphics Solutions (UGS), then into the EDS/UGS era, and ultimately to Siemens PLM and today’s Siemens Digital Industries Software. Despite ownership changes, Siemens preserved a neutral licensing stance, widely supplying competitors, while also integrating Parasolid tightly inside NX and Solid Edge. ACIS began with Spatial Technology (Spatial Corp) under Dick Sowar, then in 2000 became part of Dassault Systèmes. Dassault maintained Spatial as an arm’s-length licensing business, pairing ACIS with complementary components (notably 3D InterOp) and supporting a broad partner ecosystem, even as Dassault’s flagship CATIA/3DEXPERIENCE relies on its own CGM kernel. These lineages mattered because OEMs prize continuity: stable APIs, a predictable deprecation cadence, and backward-compatible file formats. Both stewards issued disciplined releases, invested in robustness testbeds, and surfaced diagnostics that integrators could route to their support teams. The outcome was confidence that strategic applications—PDM-integrated CAD, CAM toolpathing, or simulation pre-processing—could be built atop kernels that would still be maintained a decade later, thereby lowering lifecycle risk for software vendors and end customers alike.

• Parasolid chain: Shape Data → UGS → EDS/UGS → Siemens PLM → Siemens Digital Industries Software.
• ACIS chain: Spatial Technology → Dassault Systèmes (Spatial remains licensing-focused).
• Continuity and neutrality became as important as raw algorithmic performance.

Early adopters and platform bets

Applications that planted the flags: from Unigraphics to AutoCAD R13

The decisive early adopters anchored each kernel in distinct market segments. For Parasolid, the anchor was Unigraphics (later NX) and the Siemens ecosystem, with Solid Edge complementing the portfolio. A key expansion came when SolidWorks (founded 1993; first release 1995) selected Parasolid, propelling the kernel into the exploding mid‑range MCAD space. Decades later, the cloud era saw Onshape choose Parasolid for a browser‑native cloud CAD stack, demonstrating the kernel’s portability and scaling potential. ACIS gained massive exposure when AutoCAD R13 (1994) embedded the kernel to enable solid modeling and downstream Mechanical Desktop features, placing ACIS on millions of desktops. ACIS further permeated mid‑market and specialty tools—BricsCAD, IronCAD, Alibre, and SpaceClaim (later acquired by Ansys)—creating dense supply chains of SAT data. These platform bets formed gravitational centers: suppliers, plug‑ins, and training practices coalesced around the kernel choices, ensuring the persistence of XT and SAT files across design, analysis, and manufacturing workflows for decades.

• Parasolid adopters: Unigraphics/NX, Solid Edge, SolidWorks, Onshape.
• ACIS adopters: AutoCAD R13/Mechanical Desktop, BricsCAD, IronCAD, Alibre, SpaceClaim.
• Kernel choice influenced reseller ecosystems, training, and data pipelines.

Divergence and strategic insulation: forks and in-house kernels

As vendors matured, some insulated their flagships with proprietary kernels while preserving interoperability. Autodesk famously forked ACIS around 2001 to create ShapeManager for Inventor, giving Autodesk full control over kernel evolution while maintaining SAT compatibility bridges for exchange. Dassault Systèmes continued developing CGM for CATIA and the 3DEXPERIENCE platform, even as Spatial licensed ACIS to third parties and offered translators via 3D InterOp. PTC used its own Granite kernel within Pro/ENGINEER and later Creo. This divergence did not eliminate Parasolid and ACIS; instead, it underscored their roles as lingua francas for vast model inventories and vendor-agnostic workflows. OEMs adopted a practical stance: use in-house kernels to differentiate flagship experiences—feature recognition, parametric stability, regenerative naming—while licensing neutral kernels and translators to maximize ecosystem reach. That compromise made the market more diverse yet more interoperable, with Parasolid XT and ACIS SAT acting as persistent bridges across otherwise competing product families.

• Autodesk ShapeManager ensured internal control while retaining exchange with SAT.
• Dassault’s CGM and PTC’s Granite coexisted alongside licensed kernels.
• Forks increased innovation autonomy without severing data exchange lifelines.

Core geometric and topological model

B‑Rep, NURBS, and tolerant modeling as shared foundations

Both Parasolid and ACIS implement a classical yet highly engineered B‑Rep model: solids, sheets, and wires represented by faces, edges, and vertices anchored to analytic or spline geometry. Curves-on-surfaces encode trims in parameter space, enabling reliable construction of trimmed faces and downstream offset/fillet logic. Their geometric libraries blend exact forms (planes, cylinders, cones, spheres, tori) with NURBS for freeform, ensuring continuity control and precise evaluations for blends and lofts. Topology supports non-manifold configurations for advanced operations—ideal for sheet-metal hems, multi-body workflows, or analysis prep. Crucially, both kernels are double‑precision tolerant modelers: they maintain fuzzy equality and adaptive merging so that imperfect inputs can be healed into watertight solids. This tolerance layer entwines with every operator, from Boolean classification to edge sewing, and is surfaced through APIs so applications can set or inherit modeling tolerances. The result is a balance between mathematics and pragmatism—exact where possible, tolerant where necessary—backed by decades of regression suites that codify real-world messiness from imported STEP, IGES, or mesh‑to‑solid conversions.

• Geometry set: analytic primitives plus NURBS for complex freeform.
• Topology: supports solids, sheets, wires, and non‑manifold configurations.
• Tolerance: adaptive merging, sewing, and healing under floating‑point limits.

Boolean and intersection machinery

SSI, classification, and rollback underpin industrial modeling

The heart of robust modeling is surface–surface intersection (SSI) and classification. Both kernels compute curve/curve and curve/surface intersections in multiple spaces (3D and parametric), reconcile them under tolerance, and build consistent trims. Boolean operators then classify faces and edges against target bodies to generate splits, merges, and deletes, producing watertight results when subtracting, unioning, or intersecting. The same core machinery powers shells, drafts, and fillets: offsetting surfaces, blending through variable‑radius constructs, and knitting edges where degeneracies emerge. Degenerate cases—near‑coincident surfaces, tangent‑to‑tangent blends, sliver faces, or micro‑edges—are managed with fallback strategies and rollback to prior states, exposed via journaling APIs. Integrators lean on diagnostics to understand failures, adjust tolerances, and re‑order features. This industrialization came from decades of stress models in complex assemblies where tiny discrepancies compound. The kernels evolved adaptive step‑size control, robust trimming with re‑projection, and tie‑break logic for ambiguous topologies—techniques that, though invisible to end users, define whether a model rebuilds reliably after dozens of edits and imports.

• SSI computes intersection curves; classification decides keep/remove regions.
• Operators reuse SSI for fillet/draft/shell via offset, trim, and sew sequences.
• Rollback and journaling provide recoverability and debuggability.

API design and developer ergonomics

Procedural versus object-oriented philosophies, identifiers, and formats

Parasolid offers a procedural C API that emphasizes explicit control, high performance, and stability. Bodies, faces, and edges are manipulated through function calls, with stable identifiers and detailed journals enabling undo/redo and feature regeneration. Persistence is provided by X_T (text) and X_B (binary) formats, both widely used for exchange and archival. ACIS presents an object‑oriented C++ entity model, encouraging inheritance and composition for custom behaviors. Its SAT (text) and SAB (binary) formats mirror Parasolid’s role as de facto neutral containers within their respective ecosystems. Historically, Spatial offered source-access tiers to select licensees, enabling deep kernel customization in vertical industries; Parasolid’s path favored binary stability with extensible operators. For developers, both approaches work: procedural APIs can map neatly to feature trees and parameter solvers, while OO entities can better encapsulate semantic extensions. The shared essentials—thread-safe progress callbacks, diagnostics, memory policies, journaling, and tolerant modeling controls—enable high-quality integrations across desktop, server, and cloud deployments.

• Parasolid: procedural API, journals/rollback, X_T/X_B persistence.
• ACIS: OO entities, extensible operators, SAT/SAB persistence.
• Both: tolerance control, diagnostics, and scalable session management.

Visualization and downstream hooks

Faceting controls, exchange ecosystems, and production pipelines

While kernels focus on exact geometry, they also include fast tessellation/faceting for display and export. Both Parasolid and ACIS expose chordal deviation, angle, and normal smoothing parameters to balance fidelity with performance. Many applications pair these with specialized visualization stacks—Siemens’ JT ecosystem for lightweight assembly viewing, or Spatial’s 3D InterOp for high‑fidelity translation across CATIA, NX, Creo, and SOLIDWORKS data. This separation of concerns keeps core modeling pure while enabling downstream BOM, MBD, and PMI usage. In manufacturing, kernels output precise edge/face definitions that CAM and CMM tools rely on; in simulation, they prepare defeatured or mid-surface representations for meshing. On the cloud, server-side faceting lets thin clients stream progressive detail. The cumulative effect is a pipeline in which exact geometry remains authoritative, while optimized meshes ensure interactive feedback. Critically, tight alignment between the kernel’s topology and its facet engine reduces silhouette artifacts and selection errors, improving user confidence during sketching, selection, and assembly mating across massive datasets.

• Adjustable facet quality ensures scalable performance in large assemblies.
• JT and 3D InterOp link kernels to enterprise visualization and exchange.
• Exact B‑Rep remains the single source of truth for CAM, CMM, and MBD.

Robustness, precision and modeling scope

Industrial Booleans, blends, and the role of the application layer

Both Parasolid and ACIS are double‑precision tolerant modelers that matured to handle complex shelling, variable‑radius blending, and multi-body Booleans. Perceived differences often reflect the application layer: feature ordering, solver strategies, sketch inference, and name management across regenerations. A kernel may successfully compute a fillet set, yet the CAD system’s feature logic could create fragile dependencies or ill‑posed constraints. Conversely, excellent feature planning can make challenging kernel operations appear effortless. Where robustness truly distinguishes kernels is in their edge cases: tangent propagation across patch networks, offset collapse around tight radii, and side‑effect healing after Boolean sliver creation. Over decades, both kernels built extensive regression suites capturing such pathologies. Integrators tune tolerance policies, fallback options, and retry sequences exposed through APIs to raise success rates. Ultimately, the lesson is pragmatic: correctness depends as much on modeling strategy—sketch intent, draft surfaces before shells, isolate tricky blends—as on the underlying operators, which, in both kernels, are engineered for industrial scale.

• Kernel success depends on application‑level feature ordering and constraints.
• Pathologies: sliver faces, tangent flips, offset collapse, and gap healing.
• Regression coverage and retries are central to perceived robustness.

File formats and ecosystem inertia

XT and SAT as de facto neutral containers in long-lived supply chains

File formats cemented each kernel’s reach. Within Siemens/SOLIDWORKS/Onshape ecosystems, Parasolid XT became a practical neutral, often traveling alongside STEP but preserving kernel‑specific nuances like exact blend definitions and face IDs. In AutoCAD/BricsCAD/IronCAD lineages, ACIS SAT played the same role. The rule of thumb became “once chosen, forever supported”—OEMs learned that long-lived supply chains hinge on backward compatibility and clear deprecation paths. Both vendors invested in versioned file schemas, tolerant readers, and exporters that could bridge feature set differences across releases. The gravity of existing data—not just models, but macros, PDM metadata, and downstream manufacturing notes—makes switching costly. As a result, XT and SAT endure as reliable payloads, often embedded in compound containers (e.g., JT plus XT, DWG plus SAT). Translation stacks improved, but their success still benefits from kernels’ native persistence. This inertia is not stagnation; it is institutional memory, ensuring that a part designed decades ago can be re‑used, revised, and certified today without data loss.

• XT and SAT carry kernel‑level fidelity beyond generic STEP/IGES fields.
• Backward compatibility policies reduce lifecycle risk for OEMs and users.
• Compound containers frequently embed XT/SAT for high‑fidelity exchange.

API style and extensibility

Procedural clarity versus OO extensibility, and what integrators value

Developers gravitate to different idioms. A procedural API like Parasolid’s maps naturally to deterministic operator sequences and explicit transaction control; it meshes well with feature trees that must replay identically under regeneration. An object‑oriented model like ACIS’s excels at encapsulation: domain-specific entities can wrap standard geometry with metadata or behaviors, and licensees historically used Spatial’s source‑access options to tailor operators for vertical needs. In practice, both approaches succeed because they share the essentials—journaling, tolerance management, and stable identifiers—and both expose rich operator catalogs. Extensibility often rides on the quality of event hooks and diagnostics: being able to intercept a fillet failure, inspect candidate blends, tweak a tolerance, and retry can matter more than language paradigm preferences. Performance-sensitive teams mix patterns: procedural loops for bulk operations, OO wrappers for semantic consistency. The endgame is predictability in production: clear contracts for inputs/outputs, documented corner cases, and a release cadence that preserves behavioral invariants over years.

• Procedural clarity favors deterministic replay of feature histories.
• OO extensibility favors domain‑specific entities and metadata.
• Diagnostics and hooks often trump paradigm in day‑to‑day integration.

Business models and competitive paradoxes

Licensing competitors while protecting flagships

Perhaps the most striking dynamic is that both Siemens and Dassault license kernels to rivals. Siemens licenses Parasolid broadly—including to SolidWorks and Onshape—while retaining tight integration in NX/Solid Edge. Dassault Systèmes licenses ACIS via Spatial to companies whose products compete with the Dassault portfolio, even as CATIA/3DEXPERIENCE runs on CGM. This coexistence works because kernels are infrastructural: their value grows with ecosystem size, and their revenue and feedback loops improve robustness for everyone. Meanwhile, flagship products maintain strategic independence through in‑house kernels (ShapeManager at Autodesk, Granite at PTC, CGM at Dassault), allowing them to optimize parametrics, direct modeling tools, and large-assembly behavior without external roadmaps dictating pace. The outcome is a market where shared infrastructure reduces duplication of effort, while differentiation happens in application logic, UX, and domain expertise. It is a competitive paradox that benefits end users with better interoperability and faster innovation across product lines.

• Neutral kernel licensing expands robustness via broader real‑world exposure.
• In‑house kernels protect differentiated behavior and release autonomy.
• Interoperability remains a strategic asset rather than a zero-sum concession.

Conclusion

The reason they endured: robust B‑Rep under floating‑point limits

Parasolid and ACIS thrived because they solved the hardest, least glamorous part of CAD: making B‑Rep operations work, repeatably, under floating‑point constraints at industrial scales. Their technical differences—API philosophy, operator catalogs, XT versus SAT persistence, and historical extension options—mattered, but what mattered more was governance discipline, ecosystem gravity, and backward compatibility across decades. By separating exact geometry from visualization meshes, instrumenting tolerance throughout, and exposing reliable journals and diagnostics, they became foundations upon which entire industries could build. The vendors behind them—Siemens and Dassault via Spatial—balanced neutrality with strategic product needs, licensing broadly while nurturing internal kernels where differentiation counted most. The market rewarded this pragmatism: enormous model inventories, training practices, and supplier networks formed around these kernels, ensuring their continuing relevance even as new paradigms emerged.

• Robust SSI, classification, and healing routines define production‑grade kernels.
• Decades of backward compatibility and stable identifiers protect investment.
• Neutral licensing amplified real‑world hardening and interoperability.

The next chapter: hybrid models, parallelism, and cloud-native workflows

The future is additive, literal and figurative. Kernels are moving toward hybrids that combine B‑Rep with polygonal meshes, voxels, and implicit fields—supporting lattice structures, function‑driven thickness, and simulation‑guided morphing that classical surfaces alone cannot express. Expect tighter links to GPU and multi‑core parallel pipelines for SSI, offsetting, and tessellation. In the cloud, scalable kernel sessions will back collaborative editing, server‑side regeneration, and AI‑assisted feature synthesis, with cloud CAD proving that geometry can be a service as much as a library. Parasolid and ACIS will remain central—directly, or through forks like ShapeManager and translators such as 3D InterOp—while newer modelers complement them for implicit modeling, field‑aware optimization, and generative workflows. The winning pattern mirrors their origin story: measured evolution, strong contracts, and relentless hardening under real‑world stress. In that landscape, legacy is not inertia; it is leverage, ensuring that tomorrow’s design tools can innovate without abandoning the reliability that makes production possible.

• Hybrid B‑Rep + mesh/voxel/implicit representations broaden design space.
• Parallel kernels and GPU acceleration reduce regeneration latency.
• Cloud‑native sessions enable collaborative modeling and scalable compute.