I plan to have some updates around March. Since summer I have been in a period of extreme optimization/rearchitecturing for impressively small EXE size, low memory use, low CPU use, and efficient compute-shader-based GPU rasterization methods, with initial focus on 2D-only-at-first rendering of generic geospatial data. I did the "flashy" part first (the demo 3D engine) to prove ability, get excitement going (including my own), and set a goal for reimplementation in the performance-optimized final product. Basically, September 2023 to June 2024 was visual (groundwork, to be reused later), and since then has been technical/non-visual work (mostly). Then in the past 2 months I have created (and am finishing) an optimized D3D12 renderer - basically a month of work just to make my current simple progress on 2D multi-map tiled raster data display future-ready, and without forward progress.

I will be switching to content and actual rendering engine components soon, once I have perfected the basis of a modern, optimized graphics application to the furthest extreme reasonably possible. I am getting close, but now that I finally have a modern professional-grade Direct3D 12 renderer (written in pure Pascal/Win32 API calls and not using external D3D12 engine libraries), there are some further refactorings I can to do take advantage of that, and enable future techniques that will offer even more power savings and optimum usage of hardware.

The boring work is the most exciting to me, because everything is so efficient and stable that it will be very impressive once all the content is slowly built back in using this ultra-optimized modern GPU rendering engine.

I am designing the whole product to use GPU compute shaders to do rasterization work of multiple datasets in single draw calls. This will allow for all sorts of optimizations (like not having to render background pixels if opaque radar data is on top) as well as custom blend modes which enable very rich graphics. A lot of the improved graphical appearance will come from heavy use of real-time convolutions (distance fields, blur, glow, shadow, etc), which I have also been performance-optimizing a general method for without actually implementing beyond a basic UI effect.

The next-gen WSV3 will use deferred rendering extensively. This should decrease GPU use during loop and enable even more rich graphical effects at real-time framerates. I also haven't started another significant and necessary innovation I know I can do a great job with, which is a GPU-based timeseries raster data memory compression algorithm that can also be related to the transmission format.

Lots more "invisible" work but we do hope to soft-release an extremely simple, no-customization, 2D-only "WSV3 Core Hazard Display" (or the like) cut-down lower-price version in the summer. This will help test the new seamless VM-supporting floating licensing system and the new performant real-time server data ingest/streaming infrastructure before the major release in a year from now of WSV3 Tactical Mesoanalyst, with 3D terrain, 8x multi-maps, and everything else.

Here are some recent diagnostic screenshots showing working with basic elevation/imagery data while developing the less graphically impressive/under-the-hood optimization aspects. Check out the EXE file size 🙂



    By the way, you can fully resize/drag/dock those UI panels and they are fully responsive at 120fps with the main graphics. Everything inside the window is being equally rendered through raw GPU. This is due to my switch to open-source ImGui I mentioned in June for the user interface. There is no more slow, bloated, Windows-based traditional UI in outer frame components and resizing graphics buffers in the 3D output. The reflects a broader switch to immediate-mode vs retained-mode approaches. Launch, window resize, fullscreen switch, and UI panel resizing/drag-docking are insanely instantaneous and very satisfying. We are going against the industry trends of bloated cross-platform crap and trying to always just add more content without focusing on quality. I basically haven't even progressed the actual functional aspects of the new application in the last half year of work due to this obsession with purism, speed, efficiency, and native low-level performance. I think the industry will reward me for this. I am not the only one who is pissed that, in 2024, downloading a text editor is 500mb and runs on some gratuitous Javascript framework with all these bloated dependencies.

    I am committed to publishing a tiny installerless EXE that simply downloads in the background any additional resources it needs. The nature of the product already requires constant internet connection and downloads huge weather datasets. I am only starting to optimize the D3D12 init time, but my goal is mapping data on the screen within 1.7 seconds of pressing the "yes I'm sure this isn't a virus" button. However I'm noticing some graphics drivers are blocking the launch by one or two full seconds. Seems worse in Win11. I just bought a brand-new Intel Core Ultra Asus Zenbook S14 with the new Intel Arc graphics. While it is even faster than my dev laptop on GPU frame time (1.3ms full-screen 2880x1800 render as opposed to 2.0ms on my Asus Zenbook 12th gen with Win10 and Intel Iris Xe graphics), it randomly takes 2 full seconds to launch and inexplicably shows way more memory in Task Manager that I'm not actually allocating. So that is certainly the graphics driver on the new Intel Arc graphics and hopefully will be fixed by Intel. Internal development demo app above with Cape Cod elevation data is using about 77mb RAM in Task Manager on a 2880x1800 screen (a whole 32-bit RGBA framebuffer that size is 20.7mb). Discrete graphics cards do the same slightly delayed launch time phenomenon, noticing maybe a 0.5-1.0 second extra time on my RTX 4060 test GPU laptop (first time I am testing on discrete GPU hardware as well). But, for recommended Win10 with mainstream Intel Iris Xe integrated graphics, it will launch to first frame in a few deciseconds at most. I also wonder if Win11 is doing some stupid security scan nonsense upon launching an EXE that Win10 isn't. I will be staying on Win10 and encourage others to do the same.

    @Paul, there is one thing you have done for sure - you just absolutely blew away my mind with these 2 posts. 🤯
    My mind just can't comprehend what is cooking up on your side - it's just too awesome to be real. I can just imagine the launch date of this masterpiece.
    Paul, I am very grateful for the unimaginable amount of work and time you put in this product, that will he lifechanger for all of us here. 🙏😊 I already have said, but I will repeat - when time comes for data integration - just let me know. I would be happy to assist from my side and give insights about what might be interesting for you to consider for integration and etc. 🙂 Actually have many ideas in my head and already discussed with our colleagues at environment agency (also about the RODEO open data regulation in Europe), so maybe next year when time will come we can have chat about this - not to overwhelm you too much. 😉

      MeteoLatvia Absolutely! It is great to see you share my enthusiasm and intuitive perception about how the current generation of hardware enables there to be very impressively better real-time graphics software than is currently available, if only the hard optimization work is done beforehand. I didn't have the skill or time to do this kind of thing until 2022/2023. You can see that I am building this in in such a generic and powerful way that it will be easy to eventually incorporate all kinds of datasets and without requiring too much additional engineering work.

        Paul I am understanding your vision perfectly, altough I might not understand all of the tehnical terms and stuff, but seeing your dedication into this is purely amazing experience. 🙂
        When I am seeing that we are talking about installation and launch times in seconds and all kind of extremely sophisticated optimization that is now being worked on, that will make the software lightning fast, efficient and graphically powerful I just take my hat off for this. You have becomed true master in this field.
        Just to clarify - with the current intentions - it could be possible to display various types of let's say GRIB files for model data and it won't matter if they are GFS, ECMWF, HRRR, ICON or other format?

          MeteoLatvia The raster engine will abstract ingest (server) and visualization (client) of any 2D geospatial datasets: NWP GRIB2/NetCDF, radar, satellite, and static mapping elevation/orthoimagery data. The fact that the processing is done on the sever and streamed using optimized custom GPU rendering/adaptive compression formats is what will add value and make everything fast to download. The idea is the client itself will be excised of all the slowness and bloat of reading original heavy formats. It's not going to be a tool for local display of raw datasets/custom user inputs (maybe a different product eventually for that), but fast, bandwidth optimized streaming of important real-time datasets in an adaptive resolution way. One key area of inefficiency is making the user wait to download a heavy full-res frame of something that's only being viewed at far scale anyways. Model data is a great example of adding value here, especially because there is no temporal compression in the full-res GRIBs.

          Ironically, all the modern gaming tech for frame generation (AMD FSR 3, NVidia's Optical Flow hardware, etc) could be eventually leveraged for intelligent temporal resolution improvement of weather datasets. DX12 allows us to eventually access some of that which could be an even bigger deal for smooth model data loop graphics that are fast-loading and bandwidth optimized.

          Paul This is looking so good! I am very anxiously awaiting the "soft-launch" to help test the VM support on Macs!

            jcline After investing so heavily the last 2 months in the new ultra-modern Direct3D 12 rendering engine/port from D3D11 from scratch, and having gutted the D3D11 engine entirely on 12/4, I am horrified to see Parallels apparently still doesn't support D3D12! However, it seems there is another virtualization application called CrossOver for Mac which has DX12 support. I would be able to send you a basic D3D12 test/diagnostic Win32 app pretty soon if you wanted to experiment with this. Either way, maybe get on Parallels' case about this, as I had assumed if anything that support for D3D12 would be better than 11 at this point.

            Worst case, backporting a D3D11 engine from an optimized, modern D3D12 engine is far easier than the reverse (probably a 3 week task), so we will continue development with the new flagship modern, optimized D3D12 geospatial rendering engine with the hope that Mac virtualization tools will support it by this time next year, but with the possibility of doing a D3D11 backport to support Parallels if necessary. Or, better yet, Vulkan if the MacOS compatibility options there are as good, which has the added benefit of eventual Linux support.

              Paul I can't believe that Parallels doesn't support D3D12! It looks like VMWare Fusion supports it either, and stops at 11. It's been made completely free, and I think that's what a lot of people use. I've also used UTM before with some success, and that's also free, but it doesn't support any 3D graphics acceleration.

              I've heard of CrossOver, and have tried it with other things before. It does cost quite a bit, but it essentially runs the application inside a container and it acts like a native Mac app, so that could be a good solution. Either way, I'd definitely be down with doing whatever I can to help you test it with that!

                jcline Email sent. In summary, worst case, I can backport to D3D11 within a month or two of release if necessary for easy compatibility with off-the-shelf Mac VM options at that time.

                Speaking of which, today we are exactly 1 year out from WSV3 Tactical Mesoanalyst release. Today is the 9 year release anniversary of WSV3.

                14 days later

                I now have a tiny D3D12 engine initialization test app which you can email me if you want to run on hardware of interest. This tests a few things actually:

                1) General deployment confirmation with new ultra-robust tactical-grade tiny binary footprint code infrastructure + using UPX level 9 compression on EXE (bypassing whatever Windows/AV warnings, etc).

                2) Single-file installerless self-contained execution + profile first ever launch time with initial launch background download of 2 resource files (delete C:\ProgramData\WSV3 - the new base folder for next-gen WSV3 Tactical applications - to repeat the first-launch timing)

                3) Testing assumed write permissions to ProgramData directory and also using hardcoded path "C:\ProgramData\WSV3" - not going through the recommended OS shell calls to get the temp folder because we assume Win10 minimum and assume everything is "normal". Current EXE is programmed with hard blocking assert error pop-ups (showing source line and number) if fundamental deployment assumptions are violated. Let me know if any asserts are hit. Next-gen WSV3 makes hard assertions/assumptions that things are valid, and avoids the runtime overhead of checking errors. The easiest errors to handle are those which never happen. All the logic is being built to fail extremely early and be extremely intolerant to error conditions. This will make sure that nothing happens at all unless it happens perfectly. The use of "exceptions" has been absolutely eliminated. After public release I can decide whether to remove the blocking/annoying pop-up asserts (which should never happen) or if to devolve them into a log. This is a philosophical question, and will likely require moving many checks to initialization time.

                4) Base D3D12 engine initialization/graphics driver compatibility check (D3D12 works and can render frames with the new 2023 MSDF-based text engine you saw in WSV3 Professional V6 Prototype experimental build, which will be made into the new operational text rendering engine for next-gen)

                5) Baseline GPU performance of continuous full-monitor-refresh rate rendering of extremely simple text draw call, using the D3D12 waitable swapchain for max CPU efficiency at full framerate

                6) Testing connection to next-gen WSV3 real-time server over low-overhead WebSocket protocol + simple clock time synch (testing usage of built-in native Win32 Websocket client library in WinHTTP since Win8, assumed in Win10 minimum requirement, and testing compatibility with ordinary internet connections (runs over regular HTTP/S ports 80/443, right now only 80).

                7) Profiling first-frame launch times on subsequent non-initial EXE launches. This one I am interested in hearing about, because different graphics drivers can be very slow to create the D3D12 device. It should take 50-100ms, but I tested on the new impressive Intel Arc 140V graphics on the new Lunar Lake PCs, unfortunately the Intel Arc graphics drivers there are very new and it's taking a whole 800ms to create the D3D12 device, which is outside my control. Also my NVIDIA RTX 4060 laptop will take about that long to create the graphics device on cold launch (which is understandable in the case of a discrete vs integrated GPU), but it seems to have some sort of cache where subsequent launches are down to 200ms.

                Here is output on my primary development laptop with Intel Iris XE graphics (very fast launch / D3D12 device creation times):

                  Paul I would be happy to test on my hardware.
                  My email is: removed by moderator

                  P.S. I will also send my hardware specification after the test.

                    Would love to help out too!
                    removed by moderator

                    6 days later

                    I'd be happy to test as well. I big into the Virtualization market, Proxmox, KVM, Window and Linux Desktops . So any thing i can do to help test regarding vm testing contact me removed by moderator.

                    my email is removed by moderator I would love to test it out as well!

                      TheWeatherProdigy90 Please email me instead of vice-versa - I know, in humorous retrospect, Martin above started something of a chain reaction, which I then perpetuated. It becomes burdensome for me to copy email addresses and I do want to start scaling the testing to more clients, which is why I originally mentioned users can email me. Also, the forum is public and placing your email here might invite more spam from spambots on the internet. Shoot me an email and I will quickly send you the D3D12 test.

                        8 days later

                        Paul The bigger concern these days is that someone will phish them using a fake invite to WSV3 Tactical and the information presented here.

                        Folks, please don't put your emails anywhere on a forum that's not a private message. Publicly posted emails in connection with a request to test something is highly likely to result in an accurate spearphishing email from a malicious third party. It's an IT nightmare, please don't help the bad guys.