Since September I have ruminated on the idea of building a traditional 2D rectangular map rendering mode into WSV3 Tactical Mesoanalyst 2025. It would doubtlessly benefit the first two of the four major driving use cases which I explained in the early October post.

I was initially disfavoring attempting this before release, but now I am more strongly considering it.

The argument is simple: 3D globe rendering requires more rendering performance than 2D rendering, so merely keeping the 3D loaded in memory for instant switching but rendering the 2D instead will save power. This is easier for me to implement than a heavier system that attempts to transition resource loading/streaming between 3D and 2D modes in an attempt to also save less memory. That would be difficult and unwieldy, especially because memory savings aren't really that important when measured by power consumption (the tactical/in-field-friendly requirement) as compared to saving in rendering computation, and because the 3D rendering datastructures are already highly efficient.

This feature would be integrated within the multi-map system so users could arrange any combination and positional arrangement of visible maps as either 3D globe or 2D flat.

The biggest benefit is again rendering performance (no memory savings, as 3D map would be fully paged in background with identical logic), which could be meaningful on older hardware or when on-battery compared to 3D. Namely, the 2D map would allow for omission of the highly dense near-pixel-size triangle mesh the terrain engine has to maintain in uniform detail across the screen for terrain. Testing on my old 2013 laptop with embedded graphics, this creates significant overhead. When I set elevation exaggeration to 0 on that machine, which transitions to a very sparse triangle mesh since it is 2D, the performance is surprisingly great and holds around 45FPS. This proves the 2D map mode could have great value.

It will also enable creation of model graphics that appear more similar to the static images people share online from websites.

What are your impressions on the value of having a 2D map rendering mode? How often would you use it?

    Paul Hi Paul. While immense value clearly is being created surrounding the 3D mapping, I am very much in favor of a 2D mode (if I’m understanding properly - how WSV3 V5.9 looks now).

    Thanks.

        radioman10 Actually first-generation WSV3 is sort of 2.5D and does lack an actual 2D map renderer, which only WeatherStudio and AtmoGraph, of my past products, had had. Technically WSV3 Professional V5.9 has 3D geometry and display engines, but the camera controls were not proper 3D perspective (i.e., with camera actually moving closer to earth during zoom as opposed to scaling the FOV) until the V6 Prototype experiment from last year.

        The idea above is for true 2D with no tilt or anything. This affords the possibility for much faster rendering on old hardware. I agree, this will add value and offer maximum flexibility based on use-case.

          3 months later

          2D mode confirmed. This is hugely valuable. It allows me to rest assured that low-end hardware will still be able to render a 60FPS product with maximal value in actual informational content, worst case being the user stays on 2D to maximize framerate. The primary display is still absolutely 3D sphere, with heavily optimized rendering, but the 3D terrain with CDLOD algorithm does tax GPU on old hardware beyond optimal real-time framerates. This separation allows me to develop maximal graphics content in 3D for newer hardware (efficiently) without having to sacrifice due to old hardware, and allows old hardware to run a valuable product without having to be overly conservative in 3D. There are more users with NVIDIA discrete gaming cards than ancient 2013 Intel embedded HD laptop graphics like at least one PC in my testbed, so the threat of overly-conservative development graphics and rendering wise is just as present as the opposite extreme. The 2D/3D map separation and instant switching is a major conceptual win. I anticipate needing full support for optional diverse content styles between 2D and 3D map as well.


            21 days later

            Paul

            I suggest having a toggle in the settings that disables saving the 3D models in memory as some users may not necessarily want instant switching (or they have a lower end computer in which 3D mode wouldn't really work, in which case, having 3D terrain models loaded to memory would be useless if they can't use them without sacrificing performance)

                NinjaShuriken This would be a great idea in a traditional terrain engine, but thankfully, the efficient and modern algorithm I have implemented for 3D terrain actually doesn't use any more memory. It uses the same elevation texture data as already in use in 2D for terrain shading. It doesn't use any vertex buffers but implicitly generates the 3D terrain geometry on the fly on GPU side, minimizing memory bus transfer and concentrating the overhead in GPU fill rate/rasterization, which is desirable because this scales the best with higher end GPUs. This is a modern technique optimally suited for modern hardware. Combined with my implementation of DRR (Dynamic Resolution Rendering), I do think the 3D terrain will run impressively well on all but ancient laptops. This benefit of not having any additional terrain model assets in 3D vs 2D allows more memory to be devoted to texture tile data, which is important especially when multiple maps with totally independent camera views are visible - a feature almost certainly guaranteed at this point. Multimap diverse-camera-view display will use a decent amount of memory, but fully possible within the 8GB and even 16GB which are now commonplace.

                Since we're 64-bit exclusive now, the program will be able to use as much RAM as is available. The idea for a memory use reduction setting can apply to a maximum number of simultaneous map views setting, so that a user only needing one single map view could gain less RAM usage.