So this was a long time in coming.  For quite a long time, my procedural geometry generation system has been generating texture coordinates for the objects it makes.  This is so that (if/when desired) textures can easily be applied to the generated objects.

Texture coordinates basically work by assigning coordinates to each corner of an image;  the top left corner is (0,0), the top right is (1,0), the bottom left is (0,1), and the bottom right is (1,1).  What I’ve been doing is wrapping a texture around the objects I make, so the texture repeats some number of times, and the left and right edges of the texture touch each other.

The problem is that the vsMeshMaker utility class will not merge together vertices which have different texture coordinates — even if those texture coordinates are actually the same.

For example, in the image above, the top face of that cube has vertices with texture coordinates (0,0), (0.25,0), (0.5,0), (0.75,0), and (1.0,0).  (yes, there are five vertices defining the top face of the cube — the vertices for (0,0) and (1,0) overlap each other, and are only different for texture mapping purposes).

This situation was absurdly common;  two vertices which are exactly the same, except for the point in the texture that they’re referring to.  And even the texture coordinate is (technically) referring to the same point;  just expressed differently so that OpenGL renders the correct part of the texture map to the pixels around the vertex.  And the vsMeshMaker didn’t understand this situation, and so wouldn’t weld the vertices together.

The usual result of this (which was very common in MMORPG Tycoon 2) was that you’d get a strange lighting discontinuity along one edge of every object in the world.  In this case, there was a sharp line visible running diagonally along the top of the cube pictured here.  It’s been that way for months and months, and I’d basically been doing my best to simply look the other way, when taking screenshots.  At last, I’ve worked out how to get the vsMeshMaker to weld those vertices together correctly, without breaking the texture mapping.

Very pleased to have it working now.  And the answer made me feel silly for not having thought of it before;  don’t actually weld the vertices together, just pretend to have done so, and have the pretend-welded vertices check with each other to determine their final, welded normals.