Overview

EBGeometry is a header-only C++17 library with zero external dependencies, implemented entirely under the EBGeometry namespace (with sub-namespaces such as EBGeometry::DCEL, EBGeometry::BVH, EBGeometry::Fused, EBGeometry::PointCloud, EBGeometry::GPU, EBGeometry::Render, EBGeometry::SFC and EBGeometry::Parser for the major components). A handful of design choices recur throughout the implementation:

  • Precision templating. Every class and function is templated on a floating-point type T (almost always float or double). Precision is a compile-time choice: the library has no notion of a “current” precision at runtime, and nothing dispatches on it dynamically.

  • Plain value types everywhere, and a compiled tape for composition. The analytic shapes, the surface-mesh distance fields and the BVH unions are plain, trivially copyable value types with no virtual functions, so they can be copied to a GPU and evaluated there. Transformations and CSG combinations are described with a value-type expression builder and compiled into a Tape: one array per primitive type and a list of clauses that refer to the primitives by type and index, so that evaluating a composed object needs no virtual dispatch either. See Geometries.

  • The same acceleration structure for two different problems. Finding the closest facet in a surface mesh, and finding the closest object in a CSG union of many objects, are both, structurally, “find the closest of \(N\) things” queries. EBGeometry solves both with the same bounding volume hierarchy machinery, reducing an \(\mathcal{O}(N)\) linear scan to an \(\mathcal{O}(\log N)\) tree traversal in either case. See BVH.

  • Value types, even where topology is needed. A DCEL mesh’s half-edges, their pairs, and their owning faces are genuinely different objects referencing each other – but rather than pointers or reference-counted back-references, every such cross-reference is a plain uint32_t index into the owning mesh’s own vertex/edge/face arrays. This makes VertexT/EdgeT/FaceT themselves trivially copyable value types, the same as a bounding-volume-hierarchy node stored by index offset rather than by pointer, so both can be packed tightly in memory and, where the data layout allows it, evaluated with SIMD instructions. See DCEL and BVH.

  • SIMD as an opt-in, compile-time-detected layer. SIMD acceleration is implemented with compiler intrinsics in three places (the SoA triangle and point blocks, and PackedBVH’s child-bounding-box pruning), selected at compile time from the standard compiler-predefined ISA macros – never a runtime dispatch. See SIMD-accelerated classes.

  • Device-callable basics. Scalar helpers and numeric limits (Math::min, Math::max, Math::clamp, Math::Limits) and the fixed-size Array<T, N> replace their std counterparts throughout the library, so its device code needs no special compiler flags. See Writing device code. GPU::parallelFor and GPU::transform run a functor over many indices or inputs, in a kernel in a CUDA or HIP build and in a host loop otherwise; see Running queries on a GPU.

  • Three checking mechanisms. static_assert guards template-parameter invariants decidable at compile time; the always-on EBGEOMETRY_REQUIRE macro checks what a caller controls, once, when an object is built; the opt-in EBGEOMETRY_EXPECT macro guards internal invariants, including on hot paths. See Configuration options.

The remaining pages in this section cover each component in more detail:

  • Memory model – the placement-independent Pool/PODVector storage foundation that DCEL::MeshT, BVH::PackedBVH and the mesh SDFs, point clouds and BVH unions built from them rest on.

  • Running queries on a GPU – building for a GPU, mirroring a pool to the device, and running queries there with GPU::transform.

  • Vector types – the Vec2T/Vec3T vector types used throughout the library.

  • Geometries – shapes, the analytic shapes, the expression builder for transforms and CSG combinations, the tape that evaluates them, and the BVH unions.

  • DCEL – the half-edge (DCEL) surface mesh representation.

  • BVH – bounding volume hierarchy construction, traversal, and the packed mesh/CSG signed distance function classes built on top of it.

  • Ray queries – ray and segment queries (firstHit(), intersects()) on every kind of shape.

  • The renderer and the viewer – the renderer and the interactive viewer.

  • Octree subdivision – octree subdivision for bounding-box estimates, and normals of any function.

  • Point clouds – point-cloud BVHs and hash grids for nearest-neighbor queries.

  • Reading data – reading surface meshes from STL/PLY/OBJ/VTK files.

  • SIMD-accelerated classes – the three SIMD-accelerated classes, and exactly what is vectorized in each.