Awesome! Very impressive, Paul. Hope you have a Merry Christmas and happy holiday season.

NorthAlabamaStormChase The line in the video is testing some new, essential capabilities of the 3D geospatial vector data/GIS rendering engine for WSV3 Tactical 2025. An overarching principle of this new product is the transition to a truly 3D data viewer, eventually supporting volume rendering, with truly 3D analogues to preexisting rendering components that were essentially 2D - 2D on a 3D sphere. Now we are doing 3D on a 3D sphere.

There are two core engine abilities being tested with that line - projecting vector data to 3D terrain (which requires adaptive subdivision in the case of polylines) and "screenspace extrusion" of the line geometry as opposed to world-space extrusion.

All of WSV3's preeexisting line rendering engines have extruded the geometry in world space, which leads to terrible pixelated distortions of thin lines when you tilt the map off into the horizon (see on V6P for instance with local street data).

Screenspace lines enable rich antialiasing and SDF rendering effects, though are more expensive to render. The final GIS engine will likely support multiple line rendering modes. Thin and complex lines (like local streets) I will probably adaptively rasterize, whereas state/county lines and especially vector data objects (like warning polygons) must be extruded in screenspace for equal line width independent of perspective distortion.

The 3D capability of the rendering engine under development must be able to take the same lat/lon vector data and seamlessly project it to the terrain, or render traditionally to 2D flat sphere. In the image below, you can more clearly see the difference. The traditional non-projected and world-space-extruded lines for county and state appear "underneath" the terrain and poorly handle perspective angle. I intend to have a screenspace-projected 2D flat sphere mode as well, so the user can visually perceive the difference between top-down flat-sphere-surface projected positions and their respective 3D terrain projected counterparts "above" this, according to elevation.

There's even a concept of having all data rendering engines (vector, raster, etc) have two separate modes that seamlessly transition based on camera view: everything is 3D-terrain-projected when camera is above ground (sea-level-elevation-based raster layers have constant height above ground), and then when the user zooms-in "underneath" the terrain, the traditional 2D flat sphere projected data is displayed. Around places like Denver, this would give an accurate perception of space and elevation. From the top-down view, these two modes are identical, and for performance could automatically default to flat-sphere non-terrain projected.

Here are some images which show the difference between projecting points to the 3D terrain vs projecting points to the flat "2.5D" spherical surface equivalent (traditional WSV3).


Here are some more general progress screenshots (showing old, 2.5D flat-sphere non-terrain projected GIS lines):

    One unique aspect of the new 3D Terrain/GIS engine is the ability to optionally display terrain-occluded lines with a different style. This produces a sort of "x-ray" effect promoting better spatial perception of polyline shapes in relation to terrain. This screenshot shows an early implementation, with a rudimentary transparent-like style applied to the lines "behind" the terrain (occluded). The screenshot also shows the traditional 2D world-space-extruded non-3D-terrain-projected GIS lines, as I haven't extended the new 3D lines beyond a mere hand drawing tool yet. In the bottom-right frame, one can easily perceive the benefit of screenspace-extruded lines vs the traditional world-space-extruded lines, which are barely visible with perspective/tilt. The screenspace lines maintain constant screenspace width in pixels independent of perspective. Since they are more expensive to render, I will probably build separate line rendering pipelines for heavy local street lines (small width) and sparser, thicker line layers (such as state lines or vector objects like warning polygons) which should use the screenspace method.