Development update

eliteo

Paul, I'm loving reading all the amazing progress on WSV3TM!! I'm so incredibly excited to give this a test run at some point.

I'm starting a weather/severe coverage streaming channel on Twitch where I plan to use a VTube model and WSV3TM will be PERFECT for this streaming concept I have planned.

Paul

eliteo Thanks! This is shaping up to be the absolute most low-level optimized, low-latency, fastest performing display of geospatial raster data ever available for PC. Seeing the full resolution satellite imagery is so different from first-gen which lacks a multires tile engine and has to downscale accordingly. I am getting into the timeseries/loop aspect of the "Raster2" engine right now. Tactical Mesoanalyst will do great on streams but I do plan to have "WSV3 Graphics Producer" in 2026 built on top of the new WSV3 Tactical base engine, with particular extra abilities for streaming, show creation, higher graphics, etc - optimized for the presentation case (plugged into wall with ample resources) whereas TM is the core tech optimized for the mobile cellular LTE network storm chasing bandwidth-optimized case. Let me know if you have any specific ideas or requests for the streaming case/graphics presentation version.

eliteo

Paul Absolutely, will do! If suggestions come to mind, I'll make a separate thread. And this is so exciting to hear.

When I saw that you were going to re-write the program from the ground-up to use as minimal amount of system resources as possible, I knew the long wait was going to absolutely worth it! 🙂 Your approach to this next-generation version is definitely a trade secret that only a very few number of software devs have been able to figure out, and that gives WSV3 such a huge advantage over WeatherWise or RadarOmega, which run on WebGL, which isn't necessarily efficient.

Paul

eliteo I appreciate your intuitive appreciate for and understanding of the vision of true hardware graphics for realtime geospatial and weather data. My argument is, look at all the technology, research, and development that has been done in my "space" - primary game engine development (same kind of programming) - and all the SIGGRAPH conferences and papers on realtime rendering and such. There is such an underapplication of realtime hardware graphics in the weather community where so many workflows are dominated by slow, bloated, inefficient Javascript web browser apps and sites.

I have some videos to share soon. One is showing the launch speed of the new application. On my ASUS Zenbook with Intel Iris Xe graphics, I am getting double-click the sub-200kb EXE to smooth 120fps D3D12 graphics in less than 200ms. First-time virgin launch - no installer, no VM steps, no setup - currently sitting at sub 2.0 seconds on average WiFi connection.

Being so close to the hardware (raw bare metal Pascal code + direct OS Win32 calls + raw D3D12 graphics, GPU-rendered, zero dynamic memory, all static) allows me to optimize so many parts of the experience. The bandwidth aspect and time-to-first-useful-data is a big concern. Currently I'm in low level texture streaming and caching architecture, maximizing CPU to GPU upload bandwidth with the industrial strength MPSC lock-free atomic ring buffer approach used in most AAA-grade D3D12 engines, but next week I should be in the spot of optimizing the progressive load order and background downloading of raster loops. I intuit that the newer frames are more immediately desirable than the older frames, and that LOD jumps during timeseries animation are visually disturbing, so I'd like to apply a monotonic LOD-time curve to the downloading, prioritizing the newer frames, so you see the immediate recent storm/cloud structure motion in high res at first, with a smooth progressive refinement over the rest of the loop duration, priority-weighted towards the newer tiles, also because macro-scale motion is inferable at lower LODs.

I also thought of a unique concept I'd be interested to hear feedback on. Economically and psychologically optimizing the appearance of very rich visual density raster loops like visible satellite, I thought of a dynamic loop length based on zoom level. Right now I'd argue it's economically inefficient how there is a procrustean limit irrespective of zoom level, because at wider zooms, the same absolute spatial distance of frame-to-frame motion becomes more informationally useless, and the inverse at tighter zooms. And we have a very real bandwidth budget economic optimization as well as visual. So, the CONUS satellite frames being 5-minutely, and the MESO1 being minutely, you would want to match the frame-to-frame perceptive motion in pixels per elapsed time, which would result in a different loop length at different zoom. Maybe 8 hours national, 4 hours regional, 2 hours local. We will have full-resolution loops for everything, both spatial and temporal. So this allows the maximum amount of data and minimal waste, because at some zoom level and loop length, the MESO floater would cease to be perceptibly different from the CONUS.

Suburbazine

[unknown] rather than dictate loop length by viewport, why not just trim the actual data in use so that macro-view data is composited between frames? So take 2 frames and make them a composite single frame with some AI generated data, especially if there isn't enough actual pixel count to matter. In fact that might be a cool leverage of AI frame generation on NPUs, just lock it to non-critical layers so the actual calculations can be offloaded.

Paul

Suburbazine You always know exactly what's on my mind, even going back to your post last year about maximizing the mobile/bandwidth-optimization unique aspect, which I've subsequently embraced as the primary focus of WSV3 Tactical (vs eventual Graphics Producer) - leveraging server preprocessing and modern D3D12 iGPUs to absolutely consummately optimize the user experience of timeseries raster product viewing in a multiresolution tiled dataset-native-projection view. It's pretty likely at this point that December 13th will precede the reconstitution of the 3D engine, 2D only, because of my militant focus around perfecting and optimizing this core aspect.

Now because of the same, I have recently become opposed to temporal interpolation. I've recently decided (open to argument) it's purely a graphics/eye candy feature with no actual human mesoanalytic value. This was exacerbated by the following:

For loops, WSV3 Tactical has an extremely unique and optimal engine ability, which has only been operable really since this past Friday, of immediate mode streaming of data vs full RAM preloading.

I am currently able to view arbitrary, unbounded length loops with diverse frames at 60fps within a fixed memory budget, and not doing any preloading.

The extreme optimization of the tile engine allows maximal leveraging of your modern SSD to eliminate the retained RAM restriction, paging in new tiles along the loop scrub head relative preload window as the loop plays live.

This permits unlimited temporal resolution in theory, only bounded by disk size and network.

Because of this I can fill a global zoom CONUS domain satellite loop with probably 128 frames at full 0.5km when zoomed.

So this makes temporal interpolation even less important, because even on the aesthetic end of things, I intend to pack the base license with so high temporal res CONUS fullres visible satellite imagery that, at full loop (might still be 6 hrs limit), the frames will be so dense you wouldn't even see the difference of temporal interpolation.

I can share a video soon showing this.

There are tangible GPU rendering performance to NOT having it, as it's 2x the texture bandwidth.

So this seems like a classic case where "tactical" (unlike "graphics") actually has increased value by having only discrete frames, reaping the performance/GPU use optimization, and instead focusing on packing the highest temporal res original non-downscaled data.

But the counterargument is, just make it optional. At which point, it is deprioritized to a post-release consideration.

The visible satellite imagery really is the tech centerpiece of WSV3 Tactical. It's the perennial worst case. It's easily 10 or 20x the bandwidth of the fullest radar data.

Seeing it with smoothing off at original dataset native GOES ABI geostationary projection, with only discrete frames, no interpolation neither spatially or temporally, really gives a sense of the value of product and the Raster2 engine for streaming full res meteorological timeseries datasets.

Let me focus on getting a video out. Definitely this month.

We can always add temporal interpolation, but not having it on December 13th is part of the data-centric elitist purism I am trying to maximize.

Related: adoption of D3D12 does allow for usage theoretically of AMD FidelityFx FSR3, which I have long wondered about applicability to grayscale weather raster timeseries data. This is an experiment I look forward to doing next year. It could be viable.

radioman10

[unknown] I'm assuming by "temporal interpolation," you're describing the (artificial?) smoothing between frames that is similar to how the "Blend frames" checkbox in the Model tab works in the current iteration of WSV3?

If I understood correctly and this is what you're describing, I don't ever use that in the current version of the program.

Definitely looking forward to the high-res GOES imagery in Tactical.

Paul

radioman10 Yes exactly, "blend frames" is the pedestrian terminology - same thing. Good to know it's not a part of your workflow.

Here is the video clip showing the streaming engine performance with massive spatiotemporal resolution datasets.

https://drive.google.com/file/d/1XPGK7KoxmEeR1kuCSe2haC5AYIXV5mQL/view

Be sure to download the full original file because the Google Drive viewer will kill the resolution.

I'm pretty sure the video file is only 60fps - it was rendered at 120fps on monitor.

This is 10 hours of 5-minute GOES-19 Band 2 0.5km Visible at absolutely full spatial and temporal resolution with zero spatial or temporal smoothing. There is no temporal interpolation between frames here and yet it's packed with so much data, it looks maximally smooth.

When I zoom into Baja California Sur you can make out the original non-square imaging sensor bins/pixels in their original curved projection aligned, pristine raw state.

I might not have 10 hours of data in the base license, since I'm actually trying to reduce it to $20/month, but I would be comfortable basically promising the base data license will have 6 hours of this full-res 5-minute CONUS visible. That is 16x the data offered in the $25/month first-gen built-in Band 2 CONUS visible product, because it's downscaled 1/4th, which is 1/16th the data.

The entire EXE was using 295mb of RAM during the entire recording due to the efficient intra-loop streaming engine. The textures alone would be around 900mb if preloaded into a single view loop (first-gen has to preload everything into RAM). But comparing to the actual diverse-view case (flying the camera everywhere) isn't even possible because first-gen doesn't have a multires tile engine. Every single satellite frame you see in first-gen is one static resolution texture with zero progressive refinement.

A better comparison is to the native original NetCDF files on S3 from which the interactive, progressive loading multiresolution Raster2 engine dataset-native projection tiles are computed by the new realtime WSV3.Ingest optimized server ingest system running now semi-operationally on optimized Linux ARM64 Graviton4 servers, with similar bare metal Pascal and ultra-low latency design as the client graphics app. I spent significant time this summer on the server ingest system which generates these massive tile pyramids, churning through an SQS queue of realtime NetCDF and GRIB2 files appended the instant they are uploaded - zero polling, all event-driven.

The raw G19 CONUS Band 2 NetCDFs are about _70mb during daytime. Since the loop spans sunset/sunrise let's call the 10 hour loop 50mb per frame raw on average.

This is about 120 frames, 12/hour and 10 hours.

So the original raw data you are seeing in this video would require downloading 6,000mb - 6GB of data. You can actually do that in first-gen with the GOES-R loader tool (not 6GB worth though because of the first-gen 32-bit RAM limit).

So the streaming engine is using 32mb total of texture cache space (64 tiles in this single parameter loop) to give interactive gap-free visualization of 6GB raw loop at full res (the 300mb was the total EXE RAM usage, most of which is the background Raster1 cache and other things not even related to the Raster2 engine - maybe 100mb total at maximum is, because there is CPU metadata as well).

This is extremely promising.

Paul

In the video in my post above, when I have the UI visible, you can also see the incredible high quality native GPU font rendering using the Chlumský (2015) MSDF technique. This was previewed in V6 in the on-map text rendering but now that we are 100% pure GPU even for UI, we will have the cutting edge font rendering everywhere.

JPWX

That is incredible! Can't wait!

eliteo

Just watched the Holy crap Paul, this is insane. That is BUTTER SMOOTH. Much better improvement and definitely definitely worth the extra time and effort in re-writing this program! Well done!

As for suggestions, as some come to mind I'll let you know. But I really like the simplistic approach to version 0, gives us a good base line to start from.

And we already discussed 3D volumetric rendering, that'll be in the commercial version coming after tactical.

And as long as it has the data that old WSV3 has, manual storm tracks and ways to display street labels (just having them display automatically would work too, but I'm open to doing line-drag queries for street names so that data load is minimal), I think this will be a really solid system. But that can be focused on later on like you said, I know the the initial release is just going to focus on basic data displaying. Really looking forward to see how the new-gen WSV3 evolves over the next 1-2 years 🙂

Paul

eliteo Thanks! Yes, I am was originally upset about the evident reality of 3D terrain engine not being wise or feasible to reconstitute in time for V0 release, but now feeling great about the purist focus on having the absolutely fastest, most optimized, and mobile bandwidth connection friendly timeseries raster display in original dataset projections, where we are going to have multiple domains active concurrently, and the new special compute shader driven rendering which in one single pass rasterizes all the layers - no more GPU waste of rendering multiple layers "on top of" each other with triangle meshes. WSV3 Tactical engine is doing basically the 2D equivalent of raytracing. Given per-pixel lat-lon, it loops over the layers top to bottom and early-outs when alpha >= 1.0.

I do plan to have nationwide automatic local street mapping with angled text rendering like Google Maps. Not sure if that's in V0 but soon thereafter.

I am not opposed to having some form of 3D volume rendering in the base license. We will have to look at it data-wise. That is mid-late 2026. I have always had a dream of doing MRMS national-scale 3D volume rendering. They already have the height level data. I want to have a regular $20/month CONUS standard license and a fancy $40/month workstation license that only adds deeper resolution/limits for industrial users but the value is packed in the base license. Maybe the base license could have current realtime 3D national MRMS volume rendering and the workstation could have the animated. Because that's getting into territory where you need a better network connection/GPU anyways - maybe it's a Tactical Mesoanalyst vs Graphics Producer distinction. But I would love to have some form of volume rendering eventually in the base license.

For V0 my goal is to have the basic working version of RadarHalo Polyradial reflectivity mosaic (multiple automatic camera-based loading L2 sites with original resolution radial data blended into MRMS at range in offscreen grayscale pass before color palette, based on 120 radial chunks and not full sweeps, so realtime websockets push updates for those immediate - similar to LiveScan) and a two-domain same-parameter CONUS + MESO1 original resolution 0.5km Band 2 satellite imagery combination. The common factor here with both aspects is the unique rendering ability for multiple diverse projection/domain data of the same parameter to be synthesized into one parameter display in grayscale, before color palette application. Right now if you have the EGR add-on in first-gen, you can overlay a GOES MESO domain on top of the CONUS, but that's all it is - overlay - as opposed to actual intelligent rendering to choose the source values. As such doing that in first gen will produce artifacts for transparent areas of palettes like in Band 14. The new engine leverages GPU rasterization ability to make per-pixel decisions about, "what is the highest resolution and/or most updated original projection source to evaluate the raw grayscale value from", before color palette application.

This is a natural evolution where GPU is leveraged to remove the limitation of "which dataset do I look at", seamlessly combining multiple same-parameter diverse-domain tile pyramids so the user always sees the highest resolution/most updated data at each pixel. This represents a paradigm-shift in realtime geospatial raster dataset visualization made possible by the theoretical capabilities of modern integrated graphics chipsets if expertly exploited by a modern, compute-shader-based D3D12 rendering pipeline.

Paul

Here is the first-ever 120fps capture (and Cat 5 landfall) - meant to be viewed on a 120fps monitor to see the native framerate. Previous capture was 60fps.

https://s3.us-east-005.backblazeb2.com/wsv3-tactical-public/M/V/2025-10-29_09-02-11.zip

The zip is in spirit of WSV3 Tactical's "full resolution" philosophy.

Same dataset: 5-minute GOES-19 CONUS Band 2 0.5km Visible at absolutely full spatial and temporal resolution with zero spatial or temporal smoothing.

However now it's using the special D3D12 copy queue (https://learn.microsoft.com/en-us/windows/win32/direct3d12/user-mode-heap-synchronization) to attain a measured increase in texture streaming throughput vs usage of traditional single graphics queue - even on iGPU - which I did not realize until this month was possible (only discrete GPUs have a separate physical DMA engine for truly parallel graphics/copy execution). But you still get a benefit on iGPU because the driver can overlap the texture copies with the frame present and graphics fence wait period. This is makes WSV3 Tactical truly elite-tier modern GPU-leveraging software to reduce RAM requirement (the video above uses 24mb texture cache and 310mb RAM total - all static, zero dynamic alloc) and maximize raster data spatiotemporal resolution in ways that a heavy, inefficient browser app never could.

Also can confirm we are doing a native NWS text ingest and parsing system in bare metal Pascal on 24/7 Linux ingest server like for pyramid image processing. I am writing this referencing the 2015 code but also going straight back to NWS Directive 10-1701 etc to get the logic airtight and using tools to strictly validate it against NWS CAP alert parsed data (which are themselves not a suitable replacement as they are delayed a few seconds - measured 7s delay on Monday). The core NWS ingest engine, using a direct feed to NWWS (National Weather Wire Service) with instant server push XMPP message integration, will provide a proper backbone for a class of products that were done with secondary sources in WSV3 Professional, such as LSRs. Doing it all ourselves will retain the immediate mode, instantaneous Websocket-pushed nature of the core data streaming architecture - e.g., the LSRs would update immediately on NWS issuance and not after some delayed intermediate shapefile gets updated. All parsing occurs on server so we can fix issues or adapt to NWS changes without needing to update client binary or bloat it with string parsing code anymore.

« Previous Page