Paul Does the multi-map view feature 'sync'? Say you had two panes open and you were looking at reflectivity and SRV; could you view two or more products with the same storm on separate panes, or would you need to orient each pane to the region in question?
Trenton
TheDopplerKid I thought about this a lot in October and November. It is possible, and I intend, to give the user complete flexibility over this. There is most likely going to be a static allocation system of Maps 1 through N, likely 4 or 8, available for use and independent simultaneous on-screen display. One Map either has its own "view", or is tied to the view of another map.
However, for the raster display engine, I have decided it's probably best to have inherent 1, 2, or 4 panel parameter display, within the same map, i.e., necessitating the same view in all 4 or 2 panels. So the multi-panel parameter display does not depend at all on having different full maps.
So ideally there are both two levels of content indirection or organization: having fully separate maps (different view, timeline, content, style, etc), and then having a choice of parameter display within said map as either full, dual, or quad panel.
Then there can be an override in a given map's map settings profile to link the camera view to another map/sync positions.
What do you think about this design?
I like your idea Paul, right on point. If I am not mistaken GRLevel has the same concept but I know you will put your amazing skills at work and go BIG!
New progress shots below (late March 2024). The bloom effect is just to show/test engine ability - it might be too "flashy" to have as default, and will certainly be optional. In fact I have tentative plans to have a generic vector object bloom/shadow offset rendering setting on a per-map basis (not per-style) that would likely be limited to 1, 2, or 4 source styles - but this is all that's needed for some very nice effects.
Looks nice and great work Paul!
Paul That looks absolutely groundbreaking! It doesn't feel like WSV3 anymore with such an impressive redesign and quality that it has even in ALPHA version. Thank you for all the work!
All should add this in a beta version or something to test out
andrewtheweatherguy We are still likely a year or more away from anything releasable to test. It will be months before even I will see visuals similar to the screenshots you see above, because it was necessary to transition to other non-graphical (or at least non-3D) aspects of the project. The process requires a disciplined timeline to be able to pull-off everything I intend for the 10-year-anniversary December 2025 release.
Back to 2D possibly for the next almost year. Two halves of next-gen: Tactical and Industrial. Tactical is first (2025). Tactical has two products:
-WSV3 Tactical Mesoanalyst (The full flagship product)
-WSV3 Core Hazard Display or similar name (The half-price, ultra-simplistic, cut-down version)
The generic raster ingest and flexible composition system is going to be incredible, so much so that as of the last 2 weeks I am more excited about it than 3D.
I am going to leverage modern GPU compute shaders in an extremely unique way for weather data/geospatial raster data visualization, leading to better GPU performance, lower power usage, even smaller EXE size, and easier develpoment of eventual/possible additional renderer backends, such as Direct3D12 and/or Vulkan. This is a very hot area of active R&D I only commenced days ago. I am tempted to ditch traditional graphics pipeline and forward rendering absolutely everywhere except the 3D terrain geometry pass and basic systems like text/sprite and UI.
We have acquired much higher resolution global elevation data than currently in WSV3 Professional. Next week I might do a YouTube showing and discussing more.
Paul So great to hear updates from you again! 
I know this will be stupid question after you have made so much explaning posts l/videos, but just to confirm - as far as I understand the WSV3 Tactial is going to become all-in-one weather data displayer, for all sorts and types of data (e.g. model, radar, satellite, etc.)? With that I mean, that user will be able to import and visualize different data types, that currently are not supported (e.g. ECMWF weather model, METEOSAT satellites and other weather data outside USA). For example Estonia and Latvia has their own data format for weather radar data volumes (HDF5 I think), that are not supported by WSV3 Professional.
MeteoLatvia The Tactical Mesoanalyst user will visualize it, not import it. We import the data into our 24/7 real-time server infrastructure running ultra-fast bare-metal Pascal code, run our "special sauce" optimized geospatial data compression/streaming logic, and rapidly push to client over WebSocket/HTTP at extremely high levels of speed and bandwidth effiency compared to the absolute wasteful crap that is NetCDF, GRIB2, the NEXRAD L2 Archive format, etc.
For users to flexibly and configurably ingest direct, arbitrary, raw government data would fall under Industrial, not Tactical. Supporting this uncommon use-case significantly bloats the complexity and binary footprint, as well as exceeds most the needs and technical expertise of most users. This use case is actually the opposite of what we mean by "Tactical" Mesoanalyst; there will be "Industrial Mesoanalyst" likely for this purpose, if companies/governments want to do this. All of the datasets you mentioned I want to make available in WSV3 Tactical Mesoanalyst, possibly even with region-specific licenses, with the key distinction being we (TempoQuest) ingest the data and post-process into the super bandwidth optimized, fast-loading, efficient, proprietary raster data streaming engine being built for the product.
There is one exception: vector data ingest. This is static data from which users derive significant tactical value and should not be limited to industrial (broadcast is also under industrial). So, I intend WSV3 Tactical Mesoanalyst to have shapefile import like WSV3 Professional, and far better, supporting point objects, and competently displaying huge polygon and polyline datasets draped over 3D terrain and with better customization.
Everything else is real-time streaming bandwidth-optimized data requiring an internet connection, based on special proprietary technology being developed with modern GPU hardware, both client side and server side, to stream multiresolution hi-res 3D datasets to clients running the product on a power-constrained laptop over a bandwidth-constrained phone LTE WiFi connection within a mission-critical storm chasing context. That is the primary and ultimate usage context focus of WSV3 Tactical Mesoanalyst (see October 2023 post).
Industrial/Broadcast is a different context: plugged into the wall, less bandwidth/power resource constraint, possibly used by big companies who need to ingest their own proprietary raster data streams and/or broadcast on TV/media.
I will fight to make the Industrial side still way less expensive than WSI/Baron, but it needs to be around 5x more than Tactical, which I really want to impress people by not doubling the price, despite offering a 100x product. I would love for WSV3 Industrial Broadcast Mesoanalyst to be $100/month and available to consumers (the bosses will fight me on this) and only charge extra for TV broadcasting/certain watermark rights. Very few users have asked for custom private raster data ingest as opposed to simply me adding more data to the product.
But I will worry about Industrial/Broadcast in 2026. In the meantime WSV3 Tactical Mesoanalyst must maximize the value offered to the user at the same price-point as the current product and not more. I want to focus the functionality around the tactical in-field context and maximize content able to be delivered without raising the price.
It's possible to do this while also allowing free user import of vector data, just not local client-side raster data ingest which bloats the EXE and ruins the piracy protection model, which would require way higher prices.
Plus, you will really want to access all those datasets through native integration through our servers anyways, because they will download/display so much faster. This model also promotes global economic efficiency, decreasing the bandwidth bills of the user, us as the business, and the government, which promotes further innovation and lower prices. There's even an environmental impact optimization argument to be made.
We are getting as far away as possible from the antiquated, horrible, inefficient, security-disaster, bandwidth-wasting, slow, and frankly amateur "the Windows client EXE on the customer's computer downloads all the original heavy data straight from the government and does all the processing itself constantly on the client PC" model as possible, and that's a great thing.
In short, yes, I want to add all that data, just not to create the kind of heavy bloated product that allows the user to directly import/configure it themselves. I'm building a whole server-side engine that makes it easy for me to do just that, and we pay big bucks to process all that data so it downloads nice and fast for you with extremely low latency. Then for serious major industrial company clients, if they want to pay TempoQuest big bucks to run the same flexible ingest engine themselves on their servers, they can do that. We will be happy to pass that along in the form of low prices to consumers for the Windows PC WSV3 Tactical Mesoanalyst client application + data. You're not interested in having that as long as we make the same data available to you downstream in the app, correct? This is an example of how the price of the product to consumers can be lower and make everyone happier by choosing the right set of functionality that people actually derive value from as opposed to trying to do both client and server functionality wastefully within the same bloated EXE all on the client's computer, like WSV3 Professional. It's an amateur model that has held the product way back and I'm very excited to be going in the total opposite direction.
Thank you so much for this detailed explanation! I really appreciate it, as I know got the whole idea about the plans of the products, features, use cases, and capabilities.
Paul You're not interested in having that as long as we make the same data available to you downstream in the app, correct?
Of course, just asked, because if I remember correctly you said that the plan is to make the WSV3 become global, not just US based, and I briefly misunderstood, that you now plan to just make the WSV3 Tactical Mesoanalys for US region and not integrate more options for global products.
MeteoLatvia I am building the 3D terrain engine and generic GIS/geospatial raster data engine around one actual geographic limitation only: polar data. The simplicity of mapping a rectangular lat/lon projection onto 3D is far worth the performance benefits. The only downside to this method is the singularity/rendering disaster it creates at the poles, which you could see on older versions of Google Earth. But, applying the principles of Data Oriented Design, there isn't a need to solve this problem, because no users currently need polar data. I can have a completely separate polar stereographic map mode built later-on if anyone wants to pay for it. The tactical-grade nature involves making many tactical decisions like this, to make the most efficient and lightweight product. Instead of a bloated and inefficient solution that tries to solve all sorts of problems at once, the next-gen WSV3 philosophy applies specific optimized solutions to specific problems. Even if we don't solve all the problems at first, we can always do so in the future, and the problems that will be solved are done so in a high-quality purpose-built fashion.
Besides lacking ability to competently render polar stereographic projected data (at least first), the engine itself is absolutely being built to be international - completely location agnostic. Let's call the cutoff anywhere between 80N to 80S.
The only limit will be the availability of data. After building the engine and populating the core offering with optimized selections of operational data for the USA-focused CONUS market, I intend to go on a wild goose hunt period of data source research and acquisition. I can't worry about this until 2026 though, but Europe will be a primary target at that point, especially since I believe your satellite data is now freely available on AWS S3 public datasets, as well as much better free NWP data nowadays from ECMWF. The only bad news is I cannot justifying spending any time on that before the December 2025 release, the regular embedded products of which will be focused/optimized for CONUS.
But you've planted a very helpful seed, which is the possibility of splitting out licenses based off data coverage regions. We don't want to force US users who don't care about real-time datasets over Europe to pay for it, or vice-versa. This is essentially a pricing/business/marketing question as opposed to development, which can be handled later.
That is actually the whole intention: the power of the flexible engine being developed is to enable me to incorporate new datasets "as an administrative, not programming, matter". That has been a catchphrase of mine to explain the design of the new engine since late last year.
If you want to take some work off my shoulders, feel free to send me an email listing the total real-time vector, raster, and point datasets you would, as a European consumer, want to be included, if you were going to pay the same price as WSV3 Professional monthly subscription (in theory) for a Europe-specific data license. Based on this consumer feedback I can peruse these datasets at a high-level during exercise/walking/off-time and get a feel for any special considerations the European data formats/dissemination method differences may bring, without detracting from my mainline development schedule focused on the CONUS/USA market optimized December 2025 primary release.
Paul
The idea about the region-based subscription plans are really great. Can you please send me your e-mail? Seems like I have missed it, because I cannot access the WSV3 Professional forums now...
I will send information I recently got from EUMETNET about data regulations which will make almost all data from weather agencies in Europe free to public use in standart formats. That includes full radar volumes, SYNOP data, weather warnings, regional models etc.
MeteoLatvia Awesome. See WSV3.com for contact info.
Paul Just sent an email. 
We are definitely going to have real-time day/night map effects based on actual map time and animating with loops. I can imagine eventually how cool it would be, after doing the contour line rendering/labeling engine (see V6P experimental MSLP contour line text labels), to have labeled contours for "sunrise/astronomical twilight/nautical/civil" moving in real-time to show the different regions. 
This screenshot shows basic shader computations for this but pardon the "ugly" appearance of the unfiltered base imagery dataset. I am about to redo the export system in the new optimized D3D12 engine and will be computing mipmaps for smooth, pop-in-free zooming and quality spatial image filtering.
I even got the precision where zooming way into the sunset line shows it moving fluidly at 120fps across the screen. This will be nice to have, especially with dynamic/customizable map styles based on day/night, which is the goal.
How cool! That looks great, Paul!
jcline Thanks. It looks even better with the BMNG imagery (following screenshot also shows the seamless infinite horizontal scrolling I finally got working - this took a full week unfortunately, because it is complicated handling the IDL-crossing case (left side positive longitude right side negative) and required some deep raster tile engine refactoring work.
The new additions and their complexity with each time is just something my mind cannot comprehend... 
This is pure joy to watch the WSV3 experience rebirth and just transforming to whole new level of software.
The Day/Night band will be super useful and eye-candy feauture. I believe even not all high-end, not personal user reachable, ten of thousand of dollar graphics systems has this?
