The Institute for Digital Additive Production (DAP) at RWTH Aachen University has released an open-source geometry-processing library aimed squarely at a problem every serious AM software developer has run into: the computational geometry underneath build-preparation software is expensive, and it gets more expensive as parts get bigger and part counts climb. The library, called DAPComputationalGeometry — DAP-CG for short — is free to use, modify, and ship commercially under the permissive Boost Software License (BSL-1.0).

For makers who never touch a line of slicer code, this isn't a tool you'll download and run yourself. DAP-CG is infrastructure: a C# library meant to sit inside the CAM and pre-processing software that generates build orientations, support structures, nested build plates, sliced layers, and scan strategies for metal and polymer AM systems. But infrastructure changes are exactly the kind of thing that eventually shows up as "why did the new version of my slicer suddenly handle 200-part nest plates without falling over" — and that's the story here.

What's Actually in the Library

According to 3D ADEPT's coverage, DAP-CG is built on top of two existing open-source foundations — geometry3Sharp and Clipper2 — rather than reinventing 2D and 3D geometry primitives from scratch. What DAP added on top is the part that matters for AM specifically: algorithms for build orientation, support-structure generation, part nesting, slicing, and scan-strategy calculation, all of which are the core computational steps that turn a CAD model into machine-ready instructions. The performance-focused additions are the more technically interesting piece. 3D ADEPT details polygon aggregation and compression algorithms, robust polygon operations designed to prevent self-intersecting geometries (a chronic headache in nesting and slicing code, where a single malformed polygon can silently corrupt a build plan), and Span/SIMD-based optimizations — modern .NET performance techniques that let the library process data in contiguous memory blocks and take advantage of vectorized CPU instructions rather than looping through individual objects.

The headline number is memory, not raw speed, though the two are related: DAP reports that its polygon compression approach cut nesting memory requirements by a factor of five during the institute's own Industrialization and Digitalization of Additive Manufacturing (IDAM) project, with comparable savings observed in slicing and scan-strategy workloads. In practice, nesting — the process of packing many parts onto a build plate as tightly as possible — is one of the more memory-hungry steps in AM software because it has to track and evaluate the geometry of every part against every other part on the plate simultaneously. A fivefold reduction there is the difference between a workstation choking on a dense build and handling it comfortably.

Why an Academic Institute Is Publishing CAM Code

DAP's own site frames the release around a problem the institute says is common across AM software development: converting design data into manufacturing data is processing-time- and memory-intensive, and that overhead compounds as builds scale up in part count and complexity. Rather than publish a paper describing an algorithm and leaving implementation to whoever reads it, DAP shipped working code that CAM developers can drop into their own pipelines. That's a meaningfully different move than most academic AM research, which tends to stay in the paper-and-benchmark stage. DAP-CG comes out of IDAM, a project explicitly aimed at industrializing AM software rather than just studying it, and the Boost license choice signals intent: BSL-1.0 is about as permissive as open-source licensing gets, allowing use in closed-source commercial products without the copyleft obligations of licenses like GPL. A CAM vendor can pull DAP-CG into a proprietary product, ship it, and owe nothing back except attribution. That's a deliberate bid to get the library actually adopted inside commercial software rather than just cited in academic literature.

What It Means for Makers

Nobody reading this is going to `git clone` DAP-CG and slice a print with it directly — it's a developer library, not an end-user application, and the audience is explicitly CAM and pre-processing software teams. But the trickle-down effect is real, and it's worth understanding why. Nesting, orientation, support generation, and slicing are the computational bottlenecks that determine how long you wait before a print starts, and how big a build plate your software can handle before it runs out of memory or grinds to a crawl. Commercial and open-source slicers alike routinely struggle with large multi-part builds precisely because of the geometry operations DAP-CG targets. If even a handful of CAM tools — open-source slicers, in-house production software at bureaus, or commercial packages — adopt these algorithms or license-compatible derivatives of them, the practical result for makers is faster slicing on complex plates, fewer out-of-memory crashes on dense nests, and software that scales more gracefully as build volumes and part counts grow. There's also a plausible knock-on effect for the broader open-source AM tooling ecosystem. geometry3Sharp and Clipper2 — the general-purpose open-source libraries DAP-CG builds on — are established computational-geometry tools in their own right. A well-optimized, AM-specific layer on top of them — released under a license permissive enough for anyone to fold into their own project — could lower the bar for smaller open-source slicer and nesting projects to get production-grade performance without each one independently solving the same memory and self-intersection problems DAP has already worked through.

Bottom Line

DAP-CG isn't a new slicer or a consumer tool, and there's no indication yet that any specific mainstream slicer plans to adopt it. What it is: a free, commercially usable, purpose-built geometry engine for the specific computational bottlenecks — nesting, orientation, support generation, slicing, scan strategy — that make CAM software slow and memory-hungry on complex builds, backed by a reported fivefold memory reduction in real production use during RWTH's IDAM project. Whether it moves the needle for makers depends entirely on whether CAM developers pick it up. Given the permissive license and the concrete performance numbers behind it, that's a reasonable bet.

Sources