This thread can serve to consolidate innovative discussion around the next-generation product's rewritten and modernized terrain rendering and general GIS/vector mapping. I will get the conversation going with some early unfinished demo shots of basic 3D terrain:




    And this is with only very basic shading and before any anisotropic filtering, hypsometric tinting, coastline/ocean effects, etc. Also completely before the usage/integration of our special hi-res Landsat imagery dataset but solely with the global low-res NASA Blue Marble + SRTM elevation dataset.

      Paul

      I can't explain why, but this unfinished look already looks like a high-end, really realistic video game. It is sooo beautiful! From these first images I can already tell - WSV3 Tactial 2025 will be new era in PC weather tracking software. I have looked into these images for several minutes and can't stop enjoying how realistic it looks even without anything else, in low res. Sorry Paul for these posts from me, but I'm so excited with this development and want to share some positive feedback and can't wait for further updates! 🙂

        MeteoLatvia Just wait until you see it in motion on a 120fps monitor. It is truly stunning and requires so much discipline for me to continue work on coding versus sitting around playing with the beautiful interactive 3D virtual globe. Google Earth Desktop, by comparison, runs at 45fps on my same development PC while chewing constant high CPU and GPU even while stationary and is so awful by comparison in every way other than the depth and resolution of the datasets. While I don't have millions of dollars to give Maxar, etc. for street-level imagery, WSV3 2025 will be a Google Earth killer in terms of globe rendering graphics from the global, regional, and near-local levels.

          Paul Another reason it will even further blow away viewers when first displayed in a video screen capture is due to the special smooth vertex morphing level of detail terrain rendering algorithm I implemented.

          Filip Strugar. “Continuous distance-dependent level of detail for rendering heightmaps”.
          In: Journal of graphics, GPU, and game tools 14.4 (2009), pp. 57–74

          Also adopting some general aspects of Kurt KĂĽhnert's brilliant and recent 2022 thesis:

          KĂĽhnert, K., 2022. Methods for Automated Creation and Efficient Visualisation of Large-Scale Terrains based on Real Height-Map Data.
          https://monarch.qucosa.de/landing-page/?tx_dlf%5Bid%5D=https%3A%2F%2Fmonarch.qucosa.de%2Fapi%2Fqucosa%253A82570%2Fmets

          Paul

          I can't wait to see all of this good stuff now starting to come together in next several months. Please provide us with new teasers if you can all they way up in the development process. 🙂

            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:

            1. "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.
            2. "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:

            1. 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.
            2. 2D flat raster dataset at a fixed height in the atmosphere, user adjustable.
            3. 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.
            4. 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:

            This is all very impressive and the demo pics you have brought forth shows quite an upgrade from anything we've seen. As I get time, I'll keep looking over the forum and see if there's anything I can recommend (that's useful for everyone) but from first impressions this looks quite promising! I like that your focusing on improving areas of the software that other vendors such as WSI or Baron don't offer or if they do, they could use an upgrade. Keep up the good work Paul!

            3 months later

            Commencing initial work on formal raster tile ingest/composition system to support imagery source datasets deeper/higher resolution than the proof-of-concept global-resolution BMNG/SRTM datasets used in early screenshots above (tiles went down only to 2 degrees).

            Initial results on incorporation of proprietary LandSat seamless mosaic from EarthOnDrive acquired for usage in the new terrain engine.

            Paul Looks great, Paul. Particularly like the one showing Cabo. Nice!

              radioman10 Thanks. The Landsat base imagery is highly compelling, knowing what is possible to do with it. These screenshots are completely before correct imagery filtering/anisotropic filtering (giving a pixelated look in the meantime), before ocean rendering, before correct vector-masked coastline distinction, before dynamic hypsometric tinting, and perhaps most meaningful, using only a very rudimentary lighting/terrain shading implementation. I'm excited in particular with what should be possible with terrain shading/dynamic lightning, especially if screen-space ambient occlusion is implemented. The next-generation mapping engine needs to have advanced functionality, heretofore exclusive to high-end broadcast systems, of configurable masking abilities (such as land/ocean) and ability to terrain-shade over color raster data layers (such as temperature color fills, etc.).

              Cranked-out the final 0.125-degree tile zoom level from the proprietary Landsat mosaic base mapping, newly visible in two shots below. The final mapping will look much better than this given all the additional aspects to implement I mentioned above, but this is now representative of the highest resolution of base mapping raster color/orthoimagery data that can be expected for WSV3 Tactical 2025. In my opinion it is beyond sufficient given the zoom scales of most mesoanalytic workflows. However, there is a trick I have conceived of for even higher-res imagery, namely, a system that would download NAIP tiles and attempt to seamlessly tonemap them into the color scheme of the parent tile. Certainly not an immediate development priority. The real wows come once a new 3D GIS vector shapefile rendering engine places seamless-LOD-transition terrain-projected screen-space-extruded 3D lines on the terrain.

              Now have all the Landsat + hi-res elevation datasets seamlessly worked up to national scale 32-deg tiles. This is looking very nice before I even attempt to add blending/image-based tonemapping to the higher levels using the NASA Blue Marble Next Generation imagery, which is a valuable thing to have, not only as an aspect of the pre-processed default base mapping, but possibly even as a generic ability available to users. The raster tile composition system being built for me to myself assemble and pre-process the necessary source mapping datasets is a system which I am not building as a mere internal development tool. Rather, I am building it into the software so an eventual GIS-specific version of WSV3 2025 can be created. These are useful abilities to GIS users in a product that could be useful with zero live weather data. The GIS space is driven largely by slower CPU-based rendering software (e.g. GlobalMapper) or by expensive industrial GPU-rendered specialized software (e.g. ESRI ArcGIS). WSV3 Tactical 2025 should be a purpose-built weather data analysis application on top of an extensible, flexible, and conventional GIS application. Eventually, a special GIS-only version of the product could have data export abilities. Being able to do things like pre-process raster datasets with coastline fading/proximity and/or vector shapefile based clipping is necessary to create high quality mapping without edge discontinuities that aren't acceptable to appear in polished broadcast-ready mapping graphics.

              As I slowly develop this GIS raster composition/editing tools for tile datasets, I'll be using them to create the best looking imagery background mapping and terrain/coastline synthesis possible for the default base map of WSV3 next-generation 2025. Ocean rendering is a separate challenge that thankfully doesn't require any actual datasets but is purely rendering. The mapping engine should have embedded support for land/ocean distinction and masking based off vector shapefiles, not elevation, or perhaps, uniquely, an interaction between vector-defined and raster elevation defined land/ocean distinction.

              I think my computer might explode if this improvement stuff continues!

              • Paul replied to this.