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.

    TheDopplerKid I am testing it on a 2013 Laptop with Intel embedded graphics to ensure that old/low-end devices can still handle the massively improved detail of content scaled down a little, to maintain interactive framerate. In many ways, the next-gen WSV3 will use much less power from your computer and be more efficient. It's the current first generation product which is causing PCs to overwork, since it lacks the efficiencies of the new optimized design.

      Looks great! Is the enhanced terrain viewing going to be connected with radar imagery so it looks more unique or is it more so for viewing/decoration purposes?

      • Paul replied to this.

        OptimallyAxel Can you elaborate the concept of your question more, especially about the connection to datasets such as radar? The current first-generation WSV3 product background/terrain engine similarly serves map background/terrain imagery, but in 2D. Generally speaking, everything being built for the new product is purposefully thought out to advance the goal of tactical-grade mesoanalysis: understanding atmospheric datasets in relation to earth's surface and atmosphere. So Google-Earth-like 3D terrain and imagery is necessary for this purpose.

        At the simplest level, weather raster datasets such as radar are rendered the same way as before to a flat sphere, with 3D terrain on-top, matching only with top-down views. In another thread though I discussed ideas for different raster layer modes in relation to terrain. Vertical offsetting options will be necessary. Baron has a demo video with their system where 3D heighmapped satellite is miles above Florida, then the camera zooms under the satellite layer to reveal the surface data and mapping underneath. I'm not sure if this is related to your question though.

        Thanks for the feedback. Recent progress now allows for full range global tile viewing and generation from 32 to 1/8 degree tiles and seamless LOD transition zone blending between successive tile levels. Working on speeding up the tile data generation, then progressing to other mapping aspects like vector coastline determination/proximity fading, tonemapping/blending with BMNG, new GIS vector shapefile line renderer with 3D terrain height projection, etc.

          Paul You sort of answered my question; to elaborate, I was mainly asking if some radar data will be overlayed directly across the terrain, so you can see the radar imagery overlap the mountain for instance rather than being above it like it is currently. Hope that makes it clearer.

          • Paul replied to this.

            OptimallyAxel Now I understand; yes, see my October 10th reply above in this thread. I listed four different ways the traditional raster engine can display datasets in relation to terrain. I know for a fact the traditional flat-sphere/2D rendering, with adjustable vertical offset, is a requirement, as well as having 3D heightmapped abilities for 3D radar/satellite (that is, the height values come from the dataset itself, not from terrain).

            The additional category that I do not know about yet, as I haven't done the research and development, is a raster engine capability to "drape" datasets directly over the terrain. I do informally hope to have capability like this. This is different from terrain-shading a 2D raster dataset; from far-out zooms and top-down views, they are the same. Hard to explain but it's possible to render the raster data to flat sphere underneath the geometry of the terrain, but only colorize the terrain with transparent hillshading, so you would see the dataset underneath. This is commonly seen on TV when they show, say, a temperature color fill, but you can see the terrain shading through the colors. We will absolutely have something like that at normal regional, global, and top-down views.

            Current experimental work is being done on the fullest manifestation of that though, wherein color raster datasets are rendered directly in, with, and through the terrain geometry just like the color imagery base map data. I am building a generic tile composition infrastructure to accomplish this for the mapping data, but I definitely have had in the back of my mind that that system will be the way I try to accomplish terrain-projection of actual raster data. This is valuable for fields that are defined by a fixed height above ground.

            Idea: while the terrain-draped raster display involves corrupting the original projection of data (such as Lambert grids which define HRRR datasets, etc) to project it to the lat/lon rectangular tiles, an efficient zoom-level-based switchover could be implemented for this which falls-over to traditional flat sphere rendering of raster data at far zooms, and only performs the terrain projection at close zooms. This would maintain performance and simplicity of original incorrupt projection at far zooms, while maintaining terrain-projected raster data display at close zooms.

            These concepts are all related to a clear vision, understanding, and intuition I had after a long walk through Boston on November 7th, that the terrain engine and raster engine really should be the same thing. They've always been completely separate aspects of WSV3, but the terrain engine is really just Layer #1 of the generic raster engine. The only difference between the elevation/imagery data and the eventual weather raster datasets is the fact that it's static data (doesn't update). The computer doesn't know this - that's a very thin abstraction. Obviously the other big difference is the temporal/timeseries/animated loop aspect of weather raster data whereas terrain/imagery data is single-frame. That's fine - the terrain can be a "static" raster layer. Really trying to implement things generically and professionally like that, to make assumptions about data, and to orthogonalize/preprocess data into efficient chunks to be consumed by the renderer, with less polymorphic code behavior on the client-side. The philosophy is to convert the data into the structure needed for optimal rendering, as opposed to making complicated and inefficient rendering that can operate on a needlessly diverse set of inputs. The latter was very much the philosophy of the first-generation product and is not a tactical-grade design. The new product will be categorized by a decrease in complexity between systems where a smaller number of very powerful engines drive the program's graphics, as opposed to redundant and fractured separate systems for limited specific assets/data layers.

            These direct questions I will be experimenting, researching, and developing around right through this winter as I also build the vector mapping components.

            It will likely be until summer until I start bringing-in actual weather data for the raster display engine, but I might be able to do some experiments with 3D-terrain-projecting arbitrary raster data before then. After all, that is exactly what it's already doing with the color imagery and terrain elevation datasets.

            In addition to what I've seen so far with the terrain, I think it would be pretty cool if you were to implement a few simulators that most software's do not contain. For instance, you can create a layer of clouds above the terrain and you can have a bunch of layers that show temperature profiles surface/aloft with corresponding color palletes; and to expand even further, have the precipitation correspond with the appropriate temperatures. Similar to what the Weather Channel has, their SkyProfiler. Creating a similar interface with different height levels but with clouds above the terrain with the correspondent precipitation falling from those clouds and perhaps adding some more parameters in each height level could be cool as well. Just throwing out an idea, let me know if something like that could work out for you.

              OptimallyAxel I love this category of ideas. The emphasis of the new product is definitely to permit the 3D understanding of meteorological variables with height and to capitalize on the ability of 3D real-time GPU graphics to aid end-user mesoanalysis of a 3D atmosphere. The graphic you shared shows how only 6 vertical levels of 2D raster data, which is not excessive, can produce a useful 3D perception in the context of vertical temperature soundings. I'll be looking heavily into this when creating the forecast model data engine around the base raster display engine.

              I am over the moon with the very real possibility of Volume Rendering for radar data with WSV3 2025.

                TheDopplerKid It's happening. It's only a matter of implementation time and effort.

                Progress with smooth terrain imagery sampling/filtering and antialiasing. Using tri-linear filtering between the two nearest source texture grid levels + FXAA. This already looks great and might preclude the need to implement anisotropic filtering, at least for now.

                Paul Just watched the video and I'm blown away! It looks so super smooth even in the very early development stage as you say.

                One question - around 0:42 in video I saw very beautiful and realistic simulation of Sun light shading - is it just for development version/testing or it is really intended? 🙂

                  MeteoLatvia It's indeed a simple placeholder sun as a simple dot product in the atmosphere scattering postprocess effect, however I am sure I'll do proper point-sprite-based sun and stars. Probably will wait until I have a flexible and customizable PNG sprite customization system, as that's a final touch. But the sun position itself is not a final touch: it will be a central mapping/terrain rendering feature to have dynamic night/day map styles based on correct astronomical or user-customizable sun position. This is my current intention and desire. I have not however done the research or proof of concept on this. But I know that the worst case scenario is it would be a non-default optional high-graphics option for day/night styling for faster GPUs.

                  The whole lighting aspect of terrain is completely unfinished - just doing very basic diffuse lighting here with no specular, ambient occlusion, etc.

                  Going to look really fantastic 3 months from now - hopefully I will have the vector GIS 3D-terrain-projected screen-space-extruded polyline rendering by then, where the vector mapping data lines follow the curve of the 3D terrain surface as seen in existing industrial TV broadcast weather graphics systems. Proof of concept shot of this on manually drawn simple line data is in the other thread.

                    Paul Oh my, this looks great! Really - without anything I can already feel the power what that comes with all the 3D terrain and GIS system coming.

                    About the atmosphere scattering and effects - in my opinion it would be super eye-candy feature to have. It will add to the realistic look, and with combination of dynamic night/day map styles will look great. But I can agree - this may be as non-default option.

                    Paul, very best wishes and good luck into development, this product is shaping up to be real beast. 😉

                    P.S. Apologies for my overjoy, but this is all is great. 🙂

                    14 days later

                    Happy to be progressing to vector/polyline aspects. For tactical use case in power-constrained performance-critical environment, it might be advantageous to set the mapping engine exclusively to vector mode, or at least, omitting all raster data except for compressed elevation used to terrain-project the lines and do hillshading/terrain colorization without imagery. The first picture below shows 3D terrain projected screenspace-extruded lines which follow terrain according to real-time adjustable elevation exaggeration slider. The new vector engine will use efficient vector tiles downloaded from server for lightning fast map loading and without the necessity to deploy large, wasteful, double-precision shapefiles. I am going to use highly efficient 16-bit or possibly even 8-bit tile-relative geometry indices projected on GPU for minimal memory bandwidth and vector tile download sizes. I also aim to create a flexible topology system behind the vector mapping which consolidates overlapping line segments between, e.g., state and county outlines. Already there is single-shapefile topological simplification and edge collapsing.