Roadmap

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

Recently Landed

  • Additive Poseidons: Up until now, Poseidon works with inward facing geometry where essentially create empty space by shoving Poseidons together. Our algorithm technically also supports outward facing geometry, but we’ve kept that removed until we come up a clean and easy way to present that and allow people to configure it without everything getting too confusing.
  • Layered Intersection: Previously, you couldn’t create Poseidons that don’t intersect with other Poseidons. You might want to do this if you have a giant open space and then you want to place a building into it and then carve into that, etc.
  • Co-planar Polygon Bugs: There were quite a few bizarre issues with coplanar polygons.

Next Up

  • Oct-tree -> k-d Tree Perf Improvements
  • Job System: Next Up on our list will be moving our asynchronous operations over to the Unity Job System in order to speed up carves.

Future Improvements

  • Runtime Change Watcher - Currently we’re requesting that everyone figure out when a Poseidon changes and when a carve is needed at runtime. However, we probably understand better than you if a Poseidon needs recarving, so we’re looking into a way of exposing this as an optional way of working with Poseidon at Runtime, so that things happen more automatically.
  • 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 of 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 – When determining if two Poseidons are sisters and should carve one another, we use Axis-Aligned-Bounding-Boxes for the Intersection calculation, which has problems – namely, that it over includes things that maybe shouldn’t have been part of the Poseidon. We’re going to be switching to a KDOP26 approach to tighten the bounds around when two objects are actually intersecting with each other.