Use a standard mesh/facet format

[kephale]

Before things get too carried away in this library, we need to use a uniform mesh/facet data structure (at least the IJ-Ops DefaultMesh implementation, but hopefully this affords the opportunity to switch to a new implementation).

[kephale]

This discussion is getting revived with @skalarproduktraum.

Scenery (ThreeDViewer) as well as most of the computer graphics world + mesh file formats use vertices and indices to represent meshes. So when we read/write meshes we have to use a data structure based on vertices/indices.

DefaultMesh in imagej-ops uses a more convenient representation because the mesh is used in more complex geometric calculations. It would be a pain, and probably even inefficient to use raw arrays of vertices and indices for this. However, it is pretty painful to use DefaultMesh for file I/O as it stands.

We're floating the idea of using a data structure with just indices and vertices (and accompanying vertex data like texture coordinates and such) that closely matches Scenery's HasGeometry class. Then classes like DefaultMesh will need conversion methods to generate/consume arrays of vertices and indices.

[ctrueden]

Is it possible for the Mesh interface to implement the two different internal representations without huge performance problems on one side or the other? How expensive (in both time and space) is this conversion?

[kephale]

The 2 representations are:

1. Rendering style (i.e. Scenery): float[] for vertices, and int[] for indices of corresponding vertices in triangular(polygon in theory) faces
2. Convenient geometry (i.e. current imagej-ops):
   Mesh = List<Facet> & Set<RealLocalizable>
   Facet = List<Vertex>
   Vertex = float x,y,z (not in array form) which implements Apache math's Vector3D (link is for the implementing class)

Relevant points:

• If @skalarproduktraum can read directly into implementation 1 (via imagej-mesh, or potentially a subset like imagej-mesh-io), then Scenery would start using imagej-mesh for file I/O. Implementation 1 is also the same sort of representation that .stl, .obj, and many other file formats use for representing meshes, so it is the most natural implementation for mesh file I/O.
• Current imagej-ops for handling meshes rely heavily on implementation 2 because there are a lot of convenient geometry/math methods.
• I take issue with the particular implementation in imagej-ops because vertices are represented redundantly in 2 different data structures (i.e. there is a set of vertices represented as RealLocalizable, while the same data is also stored in Facets as a class that implements Apache math's Vector3Ds). This can be fixed relatively "easily" (might influence existing ops), but I doubt that I can take that on.

My current suggestion is:

• focus on supporting implementation 1 for file I/O
• write a converter between implementation 1 and 2 (that is what we have been doing already in ThreeDViewer)

[kephale]

However the result of this discussion turns out, a mesh should at least be a net.imagej.Data