Am I correct in the assumption that as a tile sub-divides the vertices of the parent tiles don’t change height, only that the middle of the parent tile becomes more and more defined? So the 4 vertices of the parent tile remain fixed and dividing into 4 children simply adds 5 vertices (each child shares one verticie with it’s parent.) As opposed to vertices being approximate averages at low detail levels and potentially bouncing around at each detail level. It would be nice to save locally a certain amount of geometric detail of a specific region, then only load sub-divisions as the camera either gets close to or FOV-zooms closer, and the fixed system would work very well with this scheme.
I also assume that flat-lands have less tile sub-division levels than do hilly regions, while places with steep grades have the highest number of sub-division levels.
It would be a nice option to see shaded tiles, possibly in a checkerboard fashion. No textures, rather colored polygons to easily see exactly what is occurring geometrically. This would be better than a wire-frame.
I assume geometry tile servers use geodetic lines of latitude and heights are relative to a reference ellipsoid like WGS84 in the direction of the surface normal. Perhaps some tile servers give the option for geocentric latitude and heights relative to a reference sphere? It’s around a 20000 meter ellipsoid height difference from Challenger Deep (-11000) to Everest’s summit (+9000) There’s also only a 0.03364% difference between the polar radius and equatorial radius (~21000 meters.) So using a spherical reference model seems reasonable, at least as an option.
Thanks for the link to the presentation, it looks very interesting and informative! Lots of stuff to absorb, it will take me awhile to go through it.
For now just a quick question:
Let’s say one had a 10 Gigabit/sec network connection to a terrain server. How much detail can a modern consumer computer handle, say at a constant 1080p60? Perhaps not with an infinite farclip, but what farclip/FOV combos might this be possible with, using oblique low level views in a geometrically dense area such as the Grand Canyon? Although I prefer no fog with an infinite farclip, fog with a limited farclip along with extremely high LOD might be a nice alternative option in some cases.
Of course loading full geometric detail for every scene would be insane in practice, there would be details one wouldn’t even notice and I’d rather have high FPS than details I wouldn’t notice. I just ask since I’m curious what computers can handle. With full LOD there would be some extra CPU cycles as none are used to determine LOD. Google Earth (standalone version) has ctrl-shift-a for fps,draw calls, triangles, verticies, textures, and VRAM. Does Cesium have a similar stat readout? I have to admit that I’m very impressed with Cesium’s performance. It seems to have the same performance as Google Earth even though Cesium is JavaScript and Google Earth is presumably written in C/C++. Also Cesium handles dynamic FOV nicely. I had a hard time even statically changing FOV in Google Earth, and on top of that it had clipping errors at the higher FOVs.
We avoid rendering a massive amount of terrain geometry by using horizon culling and a level-of-detail (LOD) algorithm targeting a specific pixel error.
Horizon culling is the idea that terrain that is below the horizon from the viewer’s perspective need not be rendered. Even without fog, Mount Everest becomes invisible when you move far enough away from it because its peak falls below the horizon of the curved Earth.
Cesium’s LOD algorithm guarantees that the shape of the terrain is accurate to 2 pixels (by default) once all the terrain for the given view is loaded. This accuracy is relative to the source terrain data, of course, not necessarily the real Earth. This is true, at least, when using a properly-built terrain datasource like STK World Terrain. We can’t make this guarantee with heightmap-based terrain.
You can change the maximum pixel error by setting globe.maximumScreenSpaceError.
Cesium uses multifrustum rendering to render a nearly infinite far plane without depth fighting artifacts. You can find a presentation explaining how this works here:
Altering maximumScreenSpaceError I noticed affects both geometry and texture detail. 2 pixels seems to work quite well. So going from a 2 mega-pixel display to a 8 mega-pixel display you’d obtain even higher geometric detail as it’s pixel based.
With the Earth’s curvature I’m surprised early navigators managed to find small islands, being just a few meters over the water the horizon is only about 5000 meters for objects also only a few meters over the water.
So a good way to visualize multiple frustums are ‘candy corns’. Originally I thought they may have been side by side and/or end to end. However they are only end to end, for the purpose of depth precision.
I did discover that there seems to be an overall farclip
(This was one of my early camera mods where I didn’t yet scale movements by moon distance so it’s a bit jerky)
Later I discovered the overall farclip to be 500 mega-meters, enough to explore moons around a planet, but not enough for exploring planets around a star (well that is if you want to see multiple planets in one zoomed view.) Although you can travel to the Sun 150 giga-meters away (currently a sprite, not a model), you can’t see the Earth at that distance.
Burying the camera 8000 meters under Mount Everest I noticed something peculiar.
Tiles at the same lat/lon seem to be more detailed then neighboring tiles even though they are >8000 meters away from the camera. I suppose even though its 8000 meters away the closest tile is still the one at the same lat/lon. Of course the camera isn’t supposed to be buried at all (I commented out the height cap to do this) so maybe it’s only this way when underground. Going underground would be a great option so see tunnel routes. Perhaps tiles could be rendered underground as well, with the ‘tablecloth overhangs’ going up instead of down. This method is relying on the ‘tablecloth overhangs’ to see tiles, I don’t know yet how to enable wire-frame to see tiles above ground.
Thanks for the info. I do hope that underground views become supported in the future. It’s the only way to see an underground tunnel system. Perhaps for now it could simply reverse the normals and not draw table overhangs when underground. One problem though is that there would be no horizon culling due to the lack of an horizon while underground. Perhaps an artificial horizon could be used while underground, calculated from the same lat/lon but above ground.
While working on a GTA3 CLEO mod I’ve discovered you can actually see the tunnel system as well as the ground textures from underground. It would be awesome to have this in Cesium.
Thanks for the inspector link, it’s very informative.
Translucent terrain would be great for seeing underground structures when the camera is above the terrain. When the camera is underground it would be nice if the textures were rendered on the underside of the terrain tiles, opaque or translucent. In the GTA3 video example I doubt the game-engine developer intended anyone to be underground and outside of a tunnel at the same time. I believe the reason you can see terrain texture above and below ground is because they simply ignore surface normals when drawing textures on the terrain, but for Cesium the normals could simply be reversed and skirts going up instead of down.
Besides seeing underground structures, another nifty feature of placing the camera underground would be to quickly see everything that is behind the horizon, such as what is on the opposite side of the Globe.
Not sure if this example is what you are looking for but thought it might be of interest:
Animation from Cesium subsurface earthquakes: https://www.youtube.com/watch?v=vbXf3scNL2E
If you want more examples of subsurface and transparent surfaces here at the bottom of this page is the Cesium example in the animation.