That runtime is unofficial and it was tested with mutliple atlases but not too thoroughly with a wide variety of situations. Sorry!
But the mesh renderer will always end up with multiple copies of the same material based on the draw order of the images you used and which atlases they pull from.
That's just how it needed to work in Unity because it's a 2D stacking of parts mapped to flat meshes instead of a more traditionally solid, textured 3D mesh that uses depth maps to prevent occluded objects from being drawn when they're drawn later.
If for instance, the draw order causes images to be pulled from atlases in this order:
atlas1, atlas2, atlas1, atlas3, atlas1, atlas1, atlas1, atlas2, atlas3, atlas2, atlas1, atlas2
It'll have 9 materials. 1,2,1,3,1,2,3,2,1,2
An extra copy for each time it swaps.
This also translates to 9 draw calls 'cause they inevitably can't be batched.
Unity docs say you should start worrying if your draw call reaches a few hundred on mobile, or a few thousand on desktop.
But otherwise, it shouldn't be your main concern.
It looks like the parts are quite a bit smaller than what it's supposed to be, too. Are your atlas sizes bigger than 1024x1024? (Unity's default maximum)
Note that if Unity resizes the pngs on import, it'll cause the atlases to incorrectly read the region positions. You should check and see if Unity's not actually resizing your pngs.
Unofficial runtime bugs aside, this info is mentioned here and can be seen in the examples that come with the official runtime:
https://github.com/EsotericSoftware/spi ... nity#notes
