MeshExport

Remarks

Doc 24's P7, and its own words for why it is in the plan: "this is what makes 'import from a DCC' and this document the same workflow rather than competing ones". A designer blocks out a level, an artist opens the block-out in their tool and models to it, and the level does not change shape.

⚠ The export and the bake are one piece of code, and that is the decision this phase turns on. The plan says "bake to a .vxmesh asset through the existing importer machinery" — and the existing importer machinery is ModelImporter, which reads OBJ, FBX and glTF through Assimp and compiles meshlets, bounds and distance fields out of them. Inventing a second mesh format would mean a second compiler to keep in step with the first, for geometry whose whole purpose is to be replaced. Writing the file the artist will open and pointing the entity at that is one artefact instead of two, and it makes the round trip literally the same file.

⚠ OBJ for the bake and glTF for the handoff, and they are not interchangeable. OBJ is text, is opened by everything, and carries positions, normals, coordinates and face groups — which is all a block-out has. glTF carries the same and a material per group, in one self-contained file, which is what an artist wants and what a viewer on a phone can open. Neither carries an n-gon, so both triangulate.

Methods (3)

• public static string Obj(IReadOnlyList<ExportPiece> pieces, string name = "Blockout")

  Writes pieces as a Wavefront OBJ.

• public static string Gltf(IReadOnlyList<ExportPiece> pieces, string name = "Blockout")

  Writes pieces as a self-contained glTF 2.0 document.

• public static IReadOnlyList<ExportPiece> Pieces(SceneDocument document, IEnumerable<Entity>? entities = null, Entity centre = default(Entity))

  Every entity in a document that carries geometry, ready to be written.

Used by (1)

• BlockoutHandoffVixen.Editor.Blockout