Fix KHR_materials_unlit normals, improve atmosphere appearance with Google Photorealistic 3D Tiles

[kring]

I originally set out to fix the clearly-incorrect normals for tilesets with KHR_materials_unlit (#1528). The immediate cause of the bug was that it wasn't taking into account the scaled positions introduced in #1465. But the code was also set up to compute one normal for the entire tile, based on the ellipsoid surface normal at the bounding volume origin. This was sure to create lighting discontinuities at the edges of tiles. So I decided to change that. Meshes with KHR_materials_unlit are now given a per-vertex normal which is the ellipsoid surface normal at that position, which looks a lot better. (note: the meshes already had per-vertex normals, the change is only to how they're computed)

I also noticed that we were unnecessarily duplicating vertices for unlit meshes. glTF requires generation of flat normals when normals are not included in the mesh. So, whenever we saw a mesh without normals, we were de-indexing it so that each triangle could have a consistent normal. But this was pointless and wasteful in the KHR_materials_unlit case. Fixing this reduced the mesh memory usage in the default Google Photorealistic 3D Tiles scene in the Samples from 33.3MB to 18.8MB, and should reduce the vertex transform load on the GPU by a similar amount.

With all of that fixed, I still noticed weird splotchy artifacts from the atmosphere when zoomed way out with Google Photorealistic 3D Tiles (Cesium World Terrain looked fine). A user also reported this recently in #1525. This is caused by the kind of surprising way the Google model is constructed.

A low detail mesh representation of the globe is, of course, extremely inaccurate. Any given point on the surface of the low-detail model can easily be kilometers from reality. But it doesn't matter - we usually can't even tell - because it's viewed from so far away that kilometers map to less than a pixel.

In Cesium World Terrain, the vertices on the low detail mesh are at relatively realistic locations, usually at or near peaks. Then these are connected by large triangles, so the least accurate parts are near the centers of the triangles, where the height will be much lower than reality. In Google Photorealistic 3D Tiles, the pattern is very different. Vertices can be drastically higher than any realistic height on Earth. Some low-detail vertices in GP3DT have a height above the ellipsoid of over 30km. Since Mt Everest is less than 9km about the ellipsoid, this is a bit surprising. And it caused artifacts in the atmosphere because these peaks (which could be in decidely non-peaky places like the middle of oceans) poked up through the atmosphere and hence were not shaded by it at all. Splotches.

To be clear, I'm not claiming Google is doing something wrong here. The vertex positions are presumably still falling within the geometric error bounds for the level-of-detail.

A general solution to this problem is tricky. But we can provide the tools that users need to solve it when they know they're using a tileset like this. To that end, this PR introduces a new CircumscribedGroundHeight property.

The height at which to place the bottom of the atmosphere when the player pawn is above the CircumscribedGroundThreshold. This is expressed as a height in kilometers above the maximum radius of the ellipsoid (usually WGS84). To avoid dark splotchy artifacts in the atmosphere when zoomed out far from the globe, this value must be above the greatest height achieved by any part of the tileset.

Setting it as follows produces nice results with Google Photorealistic 3D Tiles (the highlighted properties are changed from their defaults):

This PR also cleans up the CesiumSunSky Details panel by hiding the CesiumGlobeAnchor properties. It's almost never useful to change these, and it was annoying to scroll past them to change the useful properties.

Before

After

Fixes #1528
Fixes #1525

[azrogers]

This significantly improves the quality of Google P3DT in Unreal. Thanks for the change, @kring!