Development update

Paul

The next update will also debut a feature I have coveted for months but was not in a position to implement until now with live, flowing timeseries raster data. I will call it something like, "mesoanalyst-perceptive-weighted psychovisual-economy-optimized progressive temporal loop loading" or along those lines. Going back to the October 2023 manifesto here about what "tactical mesoanalysis" means, the core concept of the next-gen tactical/in-field use-case product vs the next-gen graphics/presentation/broadcast product is the assumption of finite mobile bandwidth resources and finite human mesoanalyst attention budget. Optimizing the experience of how much atmospheric understanding can be conveyed in the smallest amount of time and bandwidth overhead.

So when loading loops, the current build just loads frames/tiles in random order. The new psychovisual/perception-optimized loading enforces a breadth-first download of low-res root tiles (capturing synoptic-scale motion first), then progressively fills-in the gaps with LOD weighting towards the newer frames (capturing fine spatial details of frames closer to present, since this is more useful than older detail). As the loop continues to download and fill-in, it enforces a monotonic LOD ramp from old to new, low-res to high-res, which reduces ugly LOD flicker/transitions during frame playback during loop loading, and economically optimizes the temporal utility of new information by filling the loop in low-res to high-res for spatial refinement after all the low-res LOD0 root tiles are loaded.

Not only do the loops load much more smoothly and weighted towards the present timestamp in spatial resolution until fully loaded, but also, the throughput is much better, with proper thread saturation. So the loops should load faster than before in the next update even under the same internet speed, and the relative perception will be better, since the newer frames will fully resolve before the older frames.

AI summary notes:

Problem
Downloading tiles for a multi-frame loop is bandwidth-limited and attention-limited. A naïve “serial” or “random” load order produces:

slow time-to-first-motion (nothing useful until too many frames are complete)
distracting flicker (newer frames briefly become detailed while older frames remain extremely coarse, then oscillate)
poor psychovisual value under mobile or constrained links

Policy goal (psychovisual/mesoanalytic)
Maximize early “situational understanding” of motion and structure while the loop is still incomplete:

Motion ASAP: get a coarse representation across time quickly.
Detail where it matters: preferentially deepen detail for newer time first (closer to “now”).
No flicker: enforce a monotone resolution floor across time (older frames are never “more detailed” than newer frames during partial download).

Why this is a differentiator
Most time-series raster viewers load frames in a simple serial/random order, which is often acceptable on desktop broadband but performs poorly on constrained links.

WSV3’s ingest scheduling is intentionally optimized for:

field workflows (storm / hazard monitoring)
mobile bandwidth constraints
fast time-to-first-insight (motion + newest structure), not just “eventual completeness”

Tunables (policy knobs)
The scheduler is designed to support tunable parameters without changing the architecture:

root warmup count (how many root frames are guaranteed early)
root/detail interleave ratio
maximum LOD delta across the time window (MaxLodDelta)

Paul

Here is the scene ingest/loop download progress indicator I described above yesterday. For me this is a killer feature. If you fully load the loop, then pan/zoom the map, it will start from say 85% or whatever portion of the new-view-needed-tiles is already resident. I like to know exactly how much bandwidth I am requiring by moving/zooming the map to a different set of visible tiles, adjusting loop length, or changing parameter. For storm chasers on mobile bandwidth or anyone using this product for true tactical/in-field use on mobile bandwidth connection, this feature provides critical information. It also establishes an information baseline of bandwidth use of the current full-resolution display, so that future bandwidth savings features (like client-side downscale factor (e.g. require deeper zooms for the same max LOD level) or even specialized compressed/quantized data streams, particularly, for Level 2 single-site radar) the user can know exactly how much value is added.

Also, a new color palette presets manager, allowing for rapid click/drag cycling between max 4 palette presets:

Paul

This new build is now pushed - redownload from WSV3.com/Tactical

There's a lot of value here so I decided not to further delay until we have fully generalized "R0 canonical raster layer engine" refactored to current hardcoded R1/R2 aspects. Namely, the realtime intra-view min/max labels are hardcoded to R1 Terrain only and color palette editing is only for R2 engine (GOES-R timeseries rasters). In the next build this should be totally generalized so that you can make custom terrain elevation color palettes and have min/max labeling on R2, although that is going to require starting the logic to handle absolute units and automatic setting for imperial vs metric which is a highly necessary next step.

So to summarize, this build deploys everything in my posts since 5 days ago on Sunday 1/11:

D3D Feature Level minimum requirement raised from 11_1 to 12_0
Shader Model 5.0 to 6.0 minimum requirement (not strictly necessary right now, desirable for future, unlikely to be any FL 12_0 compliant but SM 5.1 max hardware)
General UI improvements
Total download and GPU frame time indicators on bottom corners
New industry exclusive psychovisual-economy-weighted human mesoanalyst perception ordered timeseries loop load ordering (described in detail above)
New industry exclusive view-based realtime total tile download requirement vs current load progress indicator updating in realtime with camera view and timeline changes (killer feature for mobile broadband/cellular LTE use in tactical/in-field/storm chasing contexts - described in detail above)
R1/R2 blend mode so transparent palettes are demonstrable
Early-out optimization in top-down compute-based raster engine now live in R2/R1 mode - notice GPU frame time increase from opaque palettes covering R1 Terrain background (probably this first time in history a native desktop GPU weather data display application deploys an operational top-down compute shader compositor with early-out)
Palette presets / manager UI
Updates to default palettes
Initial implementation of realtime GPU-based in-view extrema labeling (R1 only)

Paul

Note: Download/ingest for loop tiles is actually not optimized yet. Reports of faster internet PC downloading scenes slower. I have not done this profiling/optimization yet but starting likely tomorrow. So past/current builds do not yet represent intended timeline load speed which should be much improved on some hardware soon.

Paul

New build coming tonight or sooner. This is going to 1) re-institute the proper tile storage/blob indirection system for ultra-fast tile writes to disk by storing in daily append files, with only tiny pointers thereto stored in the large memory mapped cache files which was previously slowing down tile writing until I could do this work; 2) implement automatic cache deletion for old data, enabling theoretically eternal usage without exhausting disk space. This is a large milestone because now the product will technically be expected to run eternally, if I jumped off a bridge and someone else ensured the server bills got paid and that your PC never lost power or shut down for some Windows update. In reality I am going to have to have various rare updates that break the wire format and force-require the user to update the client EXE or else data will be lost, but these updates should be very rare.

To that end I am also working on an automatic "new update available" indication, which will contain an automatic advance-notice of any such rare wire format changes which would require a manual update or else data is lost. This is necessary to have since we are positioning this product as the ultimate embedded-grade tactical-grade 24/7/365 always-on runs-unti-heat-death-of-universe unbeatable stability and quality weather graphics display product for Windows PC. We went to the insane, unheard of extend of creating a D3D12 visualization client executable that uses literally zero dynamic memory allocation in the EXE itself, so it would be a pity not to have something like this.

And I do anticipate having the first said true forced update that breaks data on old versions, because I am implement a system for tracking crucial client statistics like bandwidth usage and uptime. This will allow me to justify packing more data into licenses at the same cost and also ensuring that the 24/7/365 same-instantiation uptime is achieved. I'd like your account to show the maximum uptime you ever achieved and it could even become like a gaming leaderboard, with anonymous but optionally customizable names, where you brag about how long was your maximum uptime without ever closing. This is a very healthy thing for the product ecosystem because it forces me to ensure there are never any crashes and also demonstrates to prospective users the quality of the new bare-metal EXE.

Paul

New build now pushed, as described above. You can also send me the new log file "WSV3.Tactical.Launch.txt" in %LOCALAPPDATA%/WSV3 which profiles launch time specifics. While I've seen some graphics drivers take up to ₀.7s to create the D3D12 device, the common case should be lightning-fast like this:

2026-01-20 15:54:07.745 *DB.Static.Start: 20.4ms
2026-01-20 15:54:07.752 *DB.Static.End: 26.8ms
2026-01-20 15:54:07.752 *DB.Dynamic.Start: 27.0ms
2026-01-20 15:54:07.760 *DB.Dynamic.End: 34.8ms
2026-01-20 15:54:07.760 *DB.Core.Start: 35.0ms
2026-01-20 15:54:07.771 *DB.Core.End: 45.8ms
2026-01-20 15:54:07.812 *D3D12: 86.4ms
2026-01-20 15:54:07.841 *First frame: 116.2ms

Paul

Upcoming objectives are mostly horizontal on present streampack data vs vertically expanding dataset inclusion e.g. NEXRAD/RadarHalo (March).
1) Absolute unit values in R2 engine (satellite layers) with min/max labels; 16-bit raster support/"superblock" technique (see Band 7 note on release page); animated probe point click+drop values like in first-gen 2023 V6P experimental build; multi-domain same-parameter rendering (foundational engine component before RadarHalo Polyradial Mosaic)
2) Unified SDF-based on-map UI/HUD system, in the spirit of V6P's beautiful rounded-rect SDF text frame panels with gradient/shadow/background blur effects, but this was hardcoded and never finished/generalized; overlapping with raster engine work, using the SDF UI engine to render sharp on-map palette legend bars and metadata of displayed layers, including diverse-domain timestamps and precise real-time update delay, to show off the unparalleled speed of the WSV3 Tactical server-side ingest system.

NorthAlabamaStormChase

Paul, I know this is tedious work and from the images you have posted look wonderful, I am eagerly wanting to jump on board but can only do so when there is some type of radar data available due to cost efficiency for me. Looking forward to that day and the hard work you have put into this.

Paul

NorthAlabamaStormChase I understand and agree completely. Until RadarHalo Polyradial Mosaic is operational there is intentionally no radar data because first-gen covers this very well, whereas the GOES-R satellite data (100x the data sizes as radar data) is the proper value-adding stress case for the current raster timeseries engine sandbox development (first-gen downscales satellite imagery and lacks a multiresolution tiling engine). I could actually shove MRMS HSR into the current streampack right now but want to avoid muddying the waters, to maintain the clear and distinct focus as I finish and perfect the base engine. Notably the multi-domain R2 engine ability (for multiple concurrent GOES-R domains) is a prerequisite for RadarHalo which will be multi-domain in the sense of 200+ realtime full-resolution native-projection Level 2 sites concurrently renderable in regional views and blended seamlessly into MRMS composite down-range.

Paul

Major progress on what I mentioned 9 days ago. I'll release update soon containing the following. We now have absolute unit values + unit conversion settings on R2 engine, native SDF shape + batched text rendering in core engine (min/max extrema labels no longer displaying with temporary ImGui hack).

The most significant aspects in the last week are invisible, architectural, and relating to the most elite levels of GPU rendering performance available anywhere for weather graphics on modern laptop iGPUs:
1) I am now using the D3D12 Compute queue for the R0 "stats" compute shader (which does the sampling for the min/max values and will also soon handle the animated probe points tool) (the "Compute queue" is a modern GPU API concept that on discrete GPUs unlocks true parallelism and can even theoretically benefit performance on iGPUs - see https://www.google.com/search?q=asynch+compute)
2) After 2 years of planning/conceiving this, the engine now implements my special top-down early out acrylic blur idea, both for on-map SDF labels and the ImGui sidebar with the blurred background. This optimization essentially reduces the overall GPU work needed while actually adding visual sophistication, by running a 1/4th size downscale color scene in background, running the UI blur shaders off that, and skipping the full-res pixel rasterization (early-out) in areas underneath round SDF text boxes (currently just min/max labels, but later, city labels + text rollover frames - which occupies a lot of screen space) and the right sidebar panel. So the bigger the sidebar panel the less the frame time, which is inverse of typical, where you render the whole scene and then have to render a bigger area of blur. This is a huge economic optimization to the overall per-pixel informational value per consumed unit of GPU work/system resources/power consumption.

Here is an email I wrote the other day going into more detail, with an apt screenshot of the first-gen 2023 V6P experimental build, where I debuted the basic rendering concept for the beautiful acrylic SDF text frame (which I believe Apple made standard in iOS the following year?). But that was just an experiment and very unoptimized. This is now first-class in WSV3 Tactical 2025 engine in a way that actually reduces power consumption rather than increases:

The biggest work since the last update is under the hood stuff that you'd hardly notice on your powerhouse PC. I am preparing to make the quality native rendered HUD system for SDF-based round rectangle text frames and icons/glyphs - the extrema value labels you see are currently a temporary ImGui hack. If you downloaded the 2023 V6P build and saw the extremely crisp animated rollover text boxes (signed distance field based) you'll know what I mean (screenshot below).

So this week I did work to make such blurred rectangle/text background areas (including the UI sidebar) to reap a meaningful GPU performance optimization where the GPU does not render the full scene pixels behind the blurred frame areas - but the blur is still live-rendered from behind-frame content. This is possibly by rendering the the entire scene at 1/4th resolution offscreen and blurring off that, then applying the same early out optimization for the full-resolution render underneath those boxes and UI frames. This was a fantastic investment because now I can add HUD content (like city labels using the sexy 2023 V6P blurred/embossed/glass-look SDF styles) and the GPU time for each frame will actually decrease the more area they cover, because of the unique optimization. This is a major economic optimization from philosophical principles of, "marginal amount of human mesoanalytic perception per cycle of GPU work/rasterized pixel". So to summarize, from the following V6P screenshot, all of the following blur SDF rects (2d screen overlay, map rollover text box, and city labels) will have the rendering optimization I described for Tactical Mesoanalyst, whereas V6P got the look right but was just naively rendering these on top of the map paying full price for the "underneath" pixels:

Paul

I am absolutely psyched for the most beautiful looking polylines ever seen. I am not holding back. The SDF styling engine is going to have an insane amount of possibilities and combinations for visual styling. This is absolutely within purview of Tactical and not just Graphics/Broadcast - the common theme here is the special information density optimizing psychovisual perception economized exploitation of the underneath color through special blend modes and offset/bevel styles, essentially, the 2023 SDF lines I demoed but never released - on steroids. Today we transcended a limitation of the 2023 technique where you specified just one palette across whole line width, manually creating e.g. shadow or glow with a palette. This required different palettes for different line widths. Now the engine has a canonical outer effect region with its own independent blend mode from central region and three-way AA modulation between the two regions and background scene. And some other tricks I should keep quiet about until showing them. And this will be a generic styling engine applicable to text and text frames/shapes as well - all distance fields.

I'm planning on focusing on GIS mapping and SDF 2D vector graphics this month. Once Tactical Mesoanalyst has Google Maps like GIS mapping and street level labeling, with the crisp acrylic glass SDF lines, this is really going to pop. This path is further delaying RadarHalo Polyradial Mosaic. The GOES-R data is sufficient for the engine aspects. You are going to see how much economic visual suboptimality existed in traditional geospatial raster cartography for mesoanalysis.

Paul

firenado

Its coming alive

Paul

New build is now released. This is a large update in V0 progress, first since over two weeks ago on 1/20.

Warning: the hardcoded placeholder New England line tile should download and you can actually use the placeholder SDF engine to make custom line styles, but these are only remembered from launch to launch, but I do not yet have the settings binary blob versioning migration code tested and working which will carry forward settings when I change them in an update. So, don't invest too much time in making custom SDF styles yet since you will probably lose them after future update, until I have the automatic settings version migration ability.

This is a major update implementing the things I've mentioned the last few days, as well as:
1) Raster layers now have generic min/max extrema labels
2) ImGui placeholder rendering for the same is gutted and now renders with new internal core Pascal render engine SDF-based text and text frame map labeling (which will serve city and road labels once the GIS system is in)
3) Old cache data expiration now works properly
4) Resolve midnight UTC crossover old timeline data loading
5) New SDF styling system with new canonical outer effect region and embedded/canonical AA (antialiasing) instead of relying on transverse palettes to mimic AA (width/perspective agnostic AA edges)
6) Palette system refactoring (breaking change - you will lose any raster palettes you made before) where palettes only store normalized 0-1 color scales and introduced new UI concept as "palette window" which controls range over which to apply palette (currently 0-1 unitless for R2 engine, actual absolute unit values on palette coming next), also in preparation for engine-level dynamic palettes (current R1 terrain dynamic elevation range palette is hardcoded shader trick for demo purposes)
7) "Raster stats" GPU-readback system (currently limited to per-layer whole frame single extrema values, will do more advanced labeling and animated click drop probes soon) with Compute queue optimization (discussed above) now has proper edge logic for forcing full refresh of labels on discrete content changes like clicking a new time in the timeline scrub (has to run a few frames in the background to get new values, as the stats shader is broken into quadrants to disperse the work efficiently for low GPU usage)

Paul

We will finally have a live preview for SDF line styling UI (and by subsequent extension, for SDF roundable-corner text frames + SDF text/font letter styling itself). Also experimenting with dynamic enhancement modes which apply a per-pixel color distortion to the lines based on the underlying data visuals, to maximize perception/contrast with minimal visual disturbance of the underlying data.

Paul

Debuting the "visor" system with probe tool demo case. Probe mode button is on-map native rendered separately from ImGUI detailed UI on sidebars (toggled with H key). The Visor will have V key three-mode toggle, off, on (with UI) and on (without UI).

The "Visor system" also conceptually handles all map labeling and rollover text box display, here shown with the min/max labels and manual probe points. The SDF-based rendering allows for smooth morphing of overlapping text frames allowing for less visual disturbance to the underlying map data.

Paul

I have achieved an incredible architectural milestone, the utter pinnacle of Win32 development and my goal end-state since mid-2024 since pursuing the whole bare-metal/low binary size total rewrite.

I have WSV3.Tactical.exe successfully compiling with MSVC C compiler using in-house custom transpiler from the strict subset of Pascal I have enforced for WSV3 next-gen development, "WSV3 Tactical Pascal" I should call it.

It's basically old-fashioned C-like Pascal with high enough correspondence to C that I was able to get a transpiler working.

This changes absolutely nothing visually for the client. The binary size and RAM use will be even further optimized though, because the MSVC C compiler is much more optimized than the Delphi Pascal compiler.

So the system now has the best of both worlds: for internal development/debug builds I use fast Pascal compiler (currently sub-0.3s for full client build) and retain all the clarity/perceptive benefits of Pascal syntax over C, while also being able to leverage the world's most optimized C compilers for public-facing release builds.

I will release the probe tool/line stylemap presets/Visor UI+HUD update soon and then continue with the highly powerful line style customization. In addition to raw SDF composition mode, I intend to have a simpler "explicit effects" mode for line styling where it's easy to apply Photoshop-like layer effects for the realtime line rendering, like bevel/emboss/shadow/outer glow/etc.

Paul

Terrain shading coming with next build, with ability to drape terrain shading over Raster2 engine data. On TV systems you see this effect all the time with temperature rasters rendered together with the terrain shading instead of on top.

Paul

The new build is released. Please email me or post here if you run this and everything is green. This is a major update with huge architectural under-the-hood changes. I am releasing this mid-progress on the SDF line style editor - I want to take a focused week on that and without further delaying the next update. So here it is.

1) Massive effort on line SDF styling (50% finished) and new concept of line "StyleMap" presets + common preset selector UI widget now serving raster palette presets and line presets. Note: right now line SDF styling controls are in a transitory state and the controls are overcomplicated and cluttered, but it does work. I can't guarantee your customizations will survive until final styling schemata are in place, but the migrate-on-update system is now newly deployed with this build so that could already work on next update. The line palette editor is also now working.

2) Initial implementation of dynamic range color palettes. More info below. This is the initial seed of a novel, meanigful advancement of the state of the art for weather industry geospatial realtime raster dataset rendering.

3) Debut of native Visor engine (on-map native UI cycled by V key and independent of ImGui detailed-UI interface toggled by H) + native Visor.UI layer (will become customizable, scriptable "hit windshield" system for Graphics Studio - currently used for probe tool) + Probe tool with animated time-updating click-drop points and native-rendered SDF text boxes + UI layout system to produce proper alignment of text and glyphs (nice crosshair icon included in probe label)

4) Debut of special "Superblock" 16-bit rendering mode for R2 engine. See below. Previously the note on WSV3.com/Tactical said, "Band 7 streams currently undergo an intentional preprocess temporarily corrupting its display, in preparation for planned special 16-bit raster display ability. Band 7 has special 12-bit resolution whereas 8-bit quantization is applied to other bands at negligible perceptual loss."

5) R2 engine now has smoothing option (bilinear interpolation). This is OFF by default so users can see the raw dataset-native original projection pixels and understand they are getting the real-deal with Tactical Mesoanalyst - original resolution raw data rendered on GPU with no reprojection preprocessing.

6) Major improvement to special seam-free edge reconstruction technique R2 engine uses to render at realtime rates with GPU-compute-driven realtime map projection gbuffer: fixed still-visible seam issue at far-in zooms in point sampling and refactored to support smoothing/bilinear. End result is there are now ZERO visible seams or gaps anywhere. This is a huge win for geospatial visualizaiton as packing neighbor tile texel rows and insetting (the usual, traditional seam avoidance technique for GPU tiled raster) is very expensive on ingest server.

7) Terrain shading (see above)

8) Debut of new "SpatialCache" internal GPU cache datastructure/engine which aims to handle vector tile cache, R1 static terrain texture cache, and R2 timeseries texture cache in one common GPU architecture. Nothing visual perceptible but R1 and R2 engines (terrain and GOES-R data) are now using the new GPU cache code. Test to confirm no regressions.

9) Initial public release of C-transpiled release EXE build. dcc64 (Delphi Pascal compiler) compiled size is 375kb vs msvc C-transpiled public release EXE is now 276kb, without UPX compression. Massive optimization in binary size and also measurable further RAM savings (this build will use overall a bit more RAM since we now have a sidecar texture array cache for the R1 terrain normals for terrain shading).

I will update this post shortly with detailed visual explanation and description of "superblock" 16-bit display of Band 7 data and also of the dynamic range palettes.

Paul

Here's the visual explanation for "superblock" 16-bit Band 7 rendering technique and dynamic palette range I mentioned yesterday.

This technique permits high-precision 16-bit-like dataset rendering (where 8-bit quantization produces artifacts) at one fourth the memory usage of a naive raw R16 16-bit texture format.

First-gen exhibits this problem on the 2mt pre-processed model fill. While the Model tab uses heavy F32 textures (8x the memory of BC4 format GPU 8-bit textures), the Basic Layers tab 2mt fill is server-processed to 8-bit for fast loading. With only 256 levels (8-bit), this produces visible banding artifacts as it can only encode whole integer degrees Fahrenheit:

In the GOES-R data, I am scaling all bands to 8-bit precision at virtually zero perceptive loss except for Band 7 which is natively higher precision (12-bit).

The "superblock" technique next-gen server-side encodes such data as 8-bit, but finds each 16x16 pixel neighborhood min/max values and scales the values according to that local range. Which is why Band 7 until yesterday appeared like this:

The data for the reconstruction was there, but client did not have the reconstruction logic. Now with yesterday's update the full high-precision Band 7 is properly reconstructed from the block range data in shader:

As a result you can see from the probe tool the sub-visual high precision values are palpable:

« Previous Page Next Page »