Mesh Smooooothing

Mesh Smoothing in general terms is pretty straightforward, but automating is a little harder.

I'm trying to automate my unify rather than manually specifying for each mesh. The compromise I've come up with is to record the bounds of the mesh, and compare to the bounds of the unified normal tips. Whichever normal orientation has the larger bounds for its tips must be the mesh that is the right way around.

My Mathematical solution was to determine if the normals are divergent or convergent, which kinda works for platonic solids but probably not for any of my meshes. I'd love to investigate this further as it feels like fun, but remains the wrong solution to the problem so I'll be leaving that stone unturned for a long time.

Checking the bounds should work for non enclosed meshes, which means I can split my airtank into several submeshes and resolve them individually with reasonable confidence they will all be the same way around when I recombine them.

I've also written some code I really don't like for this.  My CalculateFaceNormals(...) method takes one parameter - that it operates on via side effects and has no return value.  Likewise for my UnifyNormals method. They both take a collection of triangles. Now that its in blog form, its really apparent that they should be methods of the MeshResource class.

In short I think I really prefer
myMesh->CalculateFaceNormals();
to
CalculateFaceNormals( triangleCollection );

So in the spirit of being a Good Boy Scout I think I'll move those over before I leave the mesh code alone.  I've found it reasonable easy to read, even though I've not touched mesh code forever, and the new importer dropped straight in with no fuss.

As a consumer of the Mesh code, the class you deal with is a MeshFactory.  I use a MeshFactory to make MeshInstances for me, and put them in a MeshRenderComponent that I can attach to the scene graph.  

The MeshFactory gets MeshResources from a MeshDatabase.

All of the new import and postprocessing works behind the scenes of even the MeshDatabase. As long as the importer derives from MeshImporter which returns a MeshResource then I can keep developing new loaders and mesh processing and remain seamless to the rest of the application.

By moving my CalculateNormals() UnifyNormals() and AutoSmoothNormals() code to the MeshResource, I can apply it to MeshResources loaded from any file or even procedurally generated meshes. I'm temped to make them mesh processing components of the MeshResource because they don't apply to *every* mesh but for now I think adding them directly to the MeshResource is fine.

I'd *kind* of like to be able to apply them to MeshInstances so I could include them in a mesh view tool, and toggle each on and off but really that''s not relevant to the task so it can wait.