3D Viewer overhaul

[kephale]

<edit: We have moved beyond most of these issues. Look at SciView for updated information>

3D_Viewer is problematic these days, but sometimes still does the job and is a dependency for a number of plugins.

• ClearVolume is great, but doesn't provide all of the features of 3D_Viewer.
• Scenery does provide pretty much all of the features necessary for 3D_Viewer.
• ui-behavior provides input handling.

The idea is to replace the Java3D backend of 3D_Viewer with Scenery to help transition to a more modern 3D rendering system. In doing so, a number of features that have been built directly into 3D_Viewer can be made into core code:

• Marching Cubes already exists in imagej-ops
• Mesh smoothing
• Mesh decimation
• Mesh voxelization
• Transforms?
• Unify duplicate vertices (a number of geometric operations will fail if there are duplicate vertices)

Dealing with 3D data structures:

• Make a core mesh data structure based on imglib2-roi
• Move mesh data structures to imagej-common (inherit from imglib2-roi mesh)
• Move STL & Obj reading/writing to... imagej-common

Rendering and UI for 3D:

• Fonts/text rendering
• 3D object picking
• Context menus for objects
• Adding primitive objects to scene (landmarks/annotation)
• Adjusting object rendering properties (transparency/coloring/etc.)
• Bounding box/coordinate system indicator

Where the action is:

• MeshOps branch - port of the relevant ops
• ThreeDViewer - scenery-based 3D Viewer

Relevant Peoples:
@Dietz @tpietzsch @skalarproduktraum @ctrueden @rimadoma

[ctrueden]

Unify duplicate vertices (a number of geometric operations will fail if there are duplicate vertices)

Heh, my favorite scheme for dealing with that historically has been to randomly perturb all samples by tiny epsilons, prior to computing spatial structures such as triangulations. Very dirty, but avoids pathological situations.

Of course, I'm not suggesting we do that here... I guess it depends on the data structure. If the points are sorted, removing duplicates is easy.

[acardona]

The 3D Viewer contains a library within. Indeed, some operations (that I wrote years ago) such as mesh decimation and mesh smoothing, and saving and importing to wavefront .obj and STL formats. These could somewhat easily be separated into its own .jar library file.

Glad to read that the marching cubes that Benjamin Schmidt wrote has already been implemented as a library; I recall that Bene tried very hard to remove a bug in the marching cubes that created some meshes with non-manifold edges, but that bug likely was in the original graphics gems algorithm. Is the bug also in the imagej-ops library, I wonder?

[kephale]

@tibuch note this marching cubes comment about a potential algorithmic bug ^^^

For completeness, I'll note that we've been trying to stay close to the design choices of IJ2, which has led to:

• mesh I/O being migrated to imagej-mesh
• mesh decimation/smoothing moving to imagej-ops
• visualization/rendering living in ThreeDViewer

(To be clear: not all of this has been done yet, but these are the choices that a few folks have agreed on)

[tibuch]

The marching cubes implementation is based on this. As far as I can tell the problem of non-manifold edges/points is present in this implementation. But I am not sure if we can call it a bug.