Roadmap

Currently, Poseidon is the product of many years of us creating a tool we’d use internally. We’ve intentionally kept it simple, but we have a number of features we’d like to release in the future.

Recently Landed (3.0)

  • Runtime Change Watcher: We used to ask everyone to figure out for themselves when a Poseidon changed and when a carve was needed at runtime. No more: the new PoseidonRuntimeService and PoseidonRuntimeWatcher handle change detection, queueing, and neighbor tracking, all strictly opt-in. See Runtime Carving.
  • Mesh Cleanup: A post-carve pass that merges the slivers and scaffolding cuts CSG leaves behind back into clean polygons, dramatically reducing triangle counts. See Mesh Cleanup.
  • Worldspace Precision (Anchor-Relative Carving): Carving far from the world origin no longer degrades in precision or triggers endless rebuilds.
  • Performance, performance, performance: Pooled triangles, allocation-free steady-state carves, and much faster octree construction.

Landed a While Ago

  • Additive (Outward) Poseidons: Outward facing geometry is fully supported: carve tunnels out of a mountain, not just rooms into the void.
  • Layered Intersection: Poseidons on different layers don’t intersect each other, letting you nest carve “worlds” (a building placed in a giant open space, then carved into, etc.). See Advanced Features.
  • Co-planar Polygon Bugs: Many bizarre issues with coplanar polygons have been squashed over the years (and we keep hunting the stragglers).

Next Up

  • Job System: Moving our carving math onto the Unity Job System to greatly speed up carves. Same APIs, faster crunching.
  • Coincident-face polish: Continued work on the last remaining z-fighting/hole cases when faces sit exactly on top of each other.

Future Improvements

  • Nested Poseidons - We’re looking into a Nested Mode that would completely redo how Poseidon works. This new approach would work by using the Unity hierarchy to restrict when something carves with something else. A Poseidon that would be a child of another one would only carve against its parent and any other siblings. This would allow “prefabbed” poseidon groups.
  • Open Poseidons – Currently, one of the restrictions or problems with Poseidon are that they mostly need to be closed meshes. We’re looking into ways of removing some of those restrictions by supporting slightly more open meshes.
  • Mesh Changed Detection: We need a better way to detect when meshes change in a 3D modeler. Currently, if you take a mesh in a 3D modeler and change it, we do our best to recompute things. However in our early primitive system, we only check if THE NUMBER OF VERTICES changed, or if the number of submeshes changed (things that can be quickly computed). We should move to a different model that involves something like a mesh hash.
  • KDOP26 vs AABB (object level) – Triangle-level intersection tests already use 26-axis k-DOPs for tight bounds, but deciding whether two Poseidons are sisters still uses Axis-Aligned Bounding Boxes, which over-includes objects that aren’t really intersecting. We’d like to promote the k-DOP approach up to the object level too.