Awesome job! Great work on keeping the texel density the same. Why cogwheels though? That should make it tough to check for island rotations and seams. Is there a reason you didn't go with the traditional checker uv pattern?

The checker pattern is actually an additional and different step.

The common checker pattern exists as a regular pattern in UV space - you "paint" the checkers into the texture image. It will (as you know) show the distortion and scaling of the unwrapped UV polygons relative to the 3D polygons, and you can see how the seams between islands in UV space look when reprojected onto the model. This is of course something I also do but it's slightly boring so I don't make a picture out of it...

The cogwheels are painted on in the viewport so they exist in 3D space and are then projected onto the UV'd texture. The cogwheels therefore don't even help in the regularity of the UV pattern or the seam detection because they can cross over seams and still look fine. They are for a completely different issue: I use 3DCoat for UV'ing and painting, and Cinema4D for general work. However, the .obj and .fbx formats that is needed to transfer the models often change the point indices, which would be deadly for any morph shape on the existing model in Cinema4D if I just replace the polygon mesh. So, I transfer the UV coordinates by script based on the 3D coordinates of the points. The cogwheels indicate that the UV mapping and the point indices still match and the script didn't introduce an error, and the model didn't change in one of the many versions, and the UV didn't change in one of it's versions.

There is even a third check; 3DCoat shows the distortion and scaling issues directly as a colormap in the UV display, so often I don't need the checker pattern at all.

I tend to have quite fragmented UVs anyway, my unwrapping is fairly quick and dirty and creates more islands than absolutely necessary. Since I don't paint in texture space but in 3D, that is generally sufficient and easier on the workflow, and it helps to avoid heavy distortion which would cause trouble with the needed detail resolution.

Oh, thanks for clarifying! I usually don't have a problem with vertex reording when just sticking to fbx, but I can definitely see it happening, especially when mixing formats. If I understood you correctly, you use the cogwheel map to check if the vertex order, the model itself, or the UVs changed. I'm not really sure if that works if only the point order was mangled but every vertex is still mapped correctly to UV space. Wouldn't the model look the same when that happens? Also small changes to the model might be hard to spot too, especially small extrusions that get clamped to the same island and happen to fall on a white spot. And if the UVs changed you would only be able to see the problems with stretching or only on the seams if the texel density was retained. Maybe you could add a solid color underlying the cogwheels for each major body part. That way you would definitely see if a leg is now in previous arm space. To check if the point order changed, wouldn't a simple morph shape be enough?
But I certainly see the appeal of having a texture to quickly check for problems :D
You also seem to really know your technical 3D stuff :D Are you self-taught, or do you have an education in something cg related (if I'm allowed to ask)?

As for the vertex order: The model itself would still look the same, yes, no matter what the index of a point or polygon is. Just the topology needs to be the same. (That is actually why I didn't understand the mangled UVs at first; the model itself looked fine...) However, the UV coordinates are bound to the respective point index, not to its 3D coordinates. So if you take the UVs from one model and just transfer them to another model (supposedly the same but with different point indices) the UVs end up on the wrong point (whatever point elsewhere has that index now), and the polygon will get whatever UV mapped texture snippet its points wrongfully acquired.

Technically, I fully understand what happens. What I don't get is why the exporter or importer (whatever causes the problem; I haven't investigated the actual file formats yet and I don't feel too inspired to do so) is implemented wrongly. The point indices also determine morphshapes, vertex maps, selections, and other stuff, so it is fairly important that they never change. Yet whoever implemented that stuff just didn't care... grrr!

Yes, the cogwheels are definitely not a perfect way to see any single problems. A single white polygon, swapped for another white polygon, would be invisible. However, if the point indices or anything else gets mangled, it usually affects more than one spot, and I would not correct a single polygon anyway but just re-do the whole import. For that, the method is sufficient. But you are right, what I really need is (a) a script to check whether seemingly identical models actually have the same point indices, and (b) another script that checks whether the UV coordinates of two models are the same for each point.

Come to think of, I may want to make script © that checks whether any points of a model have moved (in comparison to another model representing an earlier state). I'll make a note.

Education, well, depends on what you call CG specific. I studied IT and had courses on vector algebra and other related stuff. I also worked through a lot of tutorials specific to my software over time... I suppose that is still called "self taught" although strictly speaking the people who did the tutorial are teaching I also have a few years of experience in 3D stuff, but until this year only as a hobby. -- 3D software these days is so enormous (not to mention the rat's tail of other necessary stuff in 3D movie making from storyboarding to camera directing to video editing) that you probably require a thorough mix of formal, tutorial, and experiential education to get ahead.