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.
- 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: Currently, you can’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 are a few issues with coplanar polygons.
- Runtime Support: Currently, Poseidon is an editor tool for level design. It’s meant to create
static geometry that exists and is saved as part of a scene. However, we’ve gotten requests from
people who are making games with Procedurally Generated levels that it would be great to have Poseidon
working at runtime. Technically, there’s nothing stopping us from making that happen, we just have
to design the APIs in a proper way and expose some currently
internallogic to allow users to kick off carve operations.
- 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.