MeshGroups.

[Richardn2002]

Me handing off existing work after the final merge of ECS refactor. Here provides math for implementing meshgroups.

Three parts:

• Testing whether a point is in a triangle.
• Efficient (but not guaranteed correct) testing of a point is in which triangle among those in a given mesh, with a bitmask constructed for the mesh.
• Given parent mesh and parent deformation, deform child mesh. Essentially letting one parent triangle drag a child vertex that is contained in it, and this drag can be chacterized by an inverse matrix, which can be reused for efficiency.

Intensive test for bitmask included (with a .png depicting the base test case), testing that bitmask yields correct test results for points with the whole test space transforming.
However, as mentioned, this bitmask method is not guaranteed to be correct, thus it is hard to define a "good enough" test case. It is easy to construct counterexamples.
An experimental attempt on dynamic bitmask step size is commented out cause test suites do not like it. A step size of 1 should be usable in actual rendering anyways.

[Richardn2002]

Out first step should be bothering Luna and try to get the 0.9 spec on meshgroups (now called "Mesh Deformer", with the legacy one named "Deformer") out.

[ArcturusEmrys]

@Richardn2002 Experimenting with this branch I've noticed a few issues:

• I have a few meshgroups which do NOT have a valid mesh. Inochi renders their children fine, but MeshGroups. #103 chokes on parsing them. Inochi specifically saves out a MeshGroup where the vertices key of the node is a normal list, but uvs and/or indicies are null or missing. (There doesn't appear to be a pattern as to which.) Catching the error and treating it as an empty list works.
• Any param that deforms a MeshGroup panics Inox2D on the first frame as no DeformStack component gets made for it.

I'm working on fixes for these. When I have them done, would you prefer I PR them against your branch so they can get included into your PR, or file a separate PR (if you don't plan to continue work on this)?

[Richardn2002]

I'm working on fixes for these. When I have them done, would you prefer I PR them against your branch so they can get included into your PR, or file a separate PR (if you don't plan to continue work on this)?

@ArcturusEmrys feel free to open a new PR, I am busy with everything in life so probably I will not continue on this anytime soon...