As you may have noticed, when a sphere (including a planet) was presented in previous screen shots, the poles were always black.  This was a cosmetic issue for the most part, so wasn't high priority to fix.  Since landing on planets is becoming more important, that little dark spot can go for miles.  So the idea was to fix the sphere issue, along with the "seam" issue that happens when trying to wrap a sphere in a single pass.  This happens because the triangles at the edge of the texture want to wrap around, but they wrap backwards.  So if the left of the triangle is on the right most side of the texture wrapping the sphere/planet, the right most side of the triangle should wrap to the left side of the texture.  And it does.  Via going completely backwards through the whole texture makes a nasty looking seam.  Again, since it was cosmetic, it wasn't high priority.  However, that has now also been fixed.  The answer is to create "dummy" points that duplicate those wrap around positions with greater than 1. positions on the texture (0.0 meaning left side, and 1.0 the right side).  This cleans up the spheres.

The next problem that really needed to be addressed in the Terrain Engine was the "MegaTriangles" were very obvious and exposed. 

Meaning, the edges while linking up, the heights are the boarder didn't match up and created cliffs all over the place with the obvious pattern that it was the larger MegaTriangle borders.  (See the left side of the screenshot).  This was a cosmetic AND functional issue, so needed to be addressed.  The main issue this occurred was because I hated how a single rectangular texture wrapped around a sphere, that the poles got so distorted.

While a properly projected texture, such as what I'm using to wrap Mars compensates for this, that doesn't help things like height maps.  So I use an isohedral layout of the sphere which means it's made up of equilateral triangles exclusively.  This solves the stretching problem, but it doesn't solve the fact that textures and height maps come in rectangular form.  There is a solve for this, of course.  There is a concept called sphering the cube (or cubing the sphere).  Which means taking a unit cube and mapping it to a unit sphere (unit meaning a shape with a radius of 1).  For my purposes, I needed to go the opposite direction and go from sphere coordinates to cube coordinates, where most of what I have seen commonly done is going from a cube to a sphere.  Because I already have the sphere well mapped out, I needed a way to figure out positioning on the cube that represented the current spherical coordinate.  If you simply extend a line from the center of the sphere to the edge of the sphere out to a cube, while it does map, it creates a nasty distortion.  However, there is  way to distribute that distortion so that the squares on the edge of the sphere cube and the middle are the same volume.  While there is a slight distortion, which can't be helped, it's far better than the alternative.  And here are my results:

I used the same grid texture I used for the white screenshot above for my tests.  I color coded the sides of the cube so I could tell what was what.  I had a small issue happen from equations failing because of the inaccuracies of floats versus doubles, but I won't get into that.  As you can see, the volume size of the squares towards the middle of a "side" of the sphere are about equal to those along the edges.  The "seams" you are seeing at those edges are the same ones and for the same reasons there were seams in the single texture on the sphere example I mentioned earlier.  While I could fix it, there isn't a point.  The way the terrain engine works, it wouldn’t' matter, although I'm sure some tweaking will be needed.  What this has let me do is arrange the height map and associated textures in a clean way with no apparent seams.   Or so I thought.

So now you can see distinct squares.  I couldn't understand what was happening at first.  So then I was back where I started with "cliffs" at the edges, just in square form rather than triangle form.  

Then I found out the "improved" perlin noise I was using failed at it's purpose, which was procedurally creating a tileable texture/height map.  Tileable means, the top/bottom and left/right match seamlessly so in a tiled layout while you can see a repeating pattern, you can't see where the texture/tile itself starts and stops.  Before you could distinctly see the borders, because they didn't match up.  So to test my theory, I switched out the texture and repeated a stock texture I used that I KNOW is tilable.  You see the result, since I used it normal mapping.  While looking too vivid, the border lines were removed, so it proved the issue was the "improved" perlin noise tiling.  So I went back to my older perlin noise code which I proved was tilable.

After some adjustments, I was able to achieve the below.  Now the Terrain doesn't have obvious artifacts at the MegaTriangle borders (which the MegaTriangles are still there, they just aren't visible).

There are still some issues, like the MegaTriangles aren't spun right to mesh up seamlessly when their resolution changes.  Basically, you never know when something doesn't actually work until everything else works as it's supposed to and exposes it never worked.  I know the "sewing" does work, this is just an issue of the MegaTriangles being spun incorrectly.  Basically, the code that compensated for how things were laid out originally now has to be disabled since now it's causing issues. Such is life.  But the main terrain is FAR better than it was, as you can see.  It also supports custom height map tiles, that I hope to see from the artists to break up the repeating tiles that is currently being used.  Mind you, a "tile" is 5 miles across, so it's big, but still, it is better to have terrain with more features on it.