MeteoLatvia You bet. I'll likely be spending the next two months on terrain alone and related aspects. Usually 80% of the end product of a certain thing or system is visible in rudimentary form after only 20% of the necessary work for a quality acceptable implementation, and these screenshots are no exception. There is no multithreaded streaming/paging system yet (just allocates GBs of memory as you fly over earth until you quit; stalls main render thread to load tiles; not yet using advanced compression formats for elevation to improve efficiency; haven't implemented special rendering technique I thought of to render the entire terrain tileset in one draw call; data is local hard-disk/no downloading; datasets heavily unfinished without neighboring-tile borders i.e. lines/cracks between tiles visible; smooth adaptive LOD vertex mesh is there but pixel shader/color LOD transitions are still discontinuous; no ocean rendering; no star/space rendering; etc.)
Open to related ideas/implementation requests in the meantime.
I have ideas for trying to use the signature "special sauce" of the terrain engine, the underlying adaptive view-distance-dependent CDLOD vertex mesh morphing (my special implementation which extends Strugar 2010 to the full-globe, spherical context, as a spatial indexing structure for the rest of the program data layers. This is necessary if anything is to interact with terrain heights. This is probably a necessity. Ideally, there are two modes for GIS line rendering:
- "Flat sphere holographic" mode: lines are rendering on-top of terrain but onto flat sphere, not corresponding to terrain heights at all. 3D terrain is there and visible for dual perception of real-world terrain vs flat-sphere-idealized mapping and weather datasets.
- "Terrain projected" mode: individual line vertices appear on the 3D heights of terrain, and perhaps there is even subdivision along long straight line segments to conform to the terrain continuously.
The 3D terrain raises all sorts of questions with combining display with 2D raster weather datasets and 3D heightmapped versions of the same, which I absolutely intend to release with for national radar and satellite (RadarOmega has a non-shaded version of this). I am open to ideas for how to answer these questions.
I do not think spending time developing a method to project 2D raster datasets onto the actual terrain surface (just like the imagery and elevation datasets) is necessarily the best use of time. Then again, MRMS is already in lat/lon projection, so for national radar it wouldn't be that hard. Perhaps that could be a special option for national radar. Anything else would involve reprojection. I could develop a sophisticated shader-based system for accessing the lat/lon projected elevation data in arbitrary shape mesh projections for common GRIB2 projections like Lambert Conformal Conic, GOES-R projections, etc.
An acceptable solution allows:
- 2D flat raster dataset (e.g. National Radar) traditionally rendered to flat surface. Appears on top of 3D terrain but not conforming to it in anyway; simply a screenspace overlay as if the terrain were still 2D.
- 2D flat raster dataset at a fixed height in the atmosphere, user adjustable.
- 2D flat raster dataset at dynamic height dictated by the current highest visible terrain elevation or multiple thereof or offset therefrom. This is an interesting idea.
- 3D heightmapped raster dataset with options 2 or 3 and optionally in-addition to the 2D dataset, so you could have national radar/satellite 3D heightmaps at elevation, then zoom "through" them, and view their 2D flat counterparts underneath. I saw a Baron system do something similar with hurricane satellite imagery over Florida at their AMS booth, however they did not replicate the 2D dataset underneath the 3D elevated heightmap.
Here's a wireframe rendering showing the new engine's CDLOD implementation - notice the uniform screen-space triangle distribution despite perspective projected view:
