Ben Russell

While AirManager is a very good product it would not be a full reproduction of the systems that IXEG have created. It would require much more work essentially duplicating systems functionality to work within AirManager. The technology proposed earlier in the thread should allow me to just export some pictures of what IXEG have already created, these are then displayed remotely as per user setup. ...close, but different.

If there are any other bits of software that people are using to achieve this sort of thing please post them here for review. Best solution wins.

Thanks for the detailed reply. I'll look into the provided links and see what we can do to make it happen. It won't be in v1.0 but you'll probably see support for this sort of thing before Christmas. (I'm responsible for the plugin(Gizmo64) that underlies all of IXEG's scripting. Big changes like this are going to have to be dealt with by me.)

Do you have links to the "replication software as we already use for BMS" ?

Are they out of synch by seconds, minutes or milliseconds? Is your network wired or wireless?

Clearly I'm too tired. People work super hard on this stuff. I feel it's important not to trivialise that. For the entire audience we deal with. Sometimes that means a few extra words. Non issues clearly grow out of hand way to fast. And this thread is a non-issue non-issue. It's also frustrating that the number one issue we're hitting at the moment is VRAM fragmentation due to VRAM pressure. There's just not much to go around sometimes. Anyway....... with five layers and multiple clouds types and a wide area, it's a fun volumetric data problem. It'll be fun to see what we (*cough*Frank*cough*) can come up with.

Last time I looked Joan was using an external program to process the NOAA data. http://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/ This processor program is between 8 and 20 megs in source code form. A non-trivial amount of functionality to try and directly integrate into a plugin. Joan calls(called?) it as a system utility from a Python thread, something which can lead to jitters because of the technical nature of Python threading being imperfect for this task. While the data is on disk it's not really a simple matter of just loading it up and reading it in, even given all the source code to do it. The NOAA X-Plane package uses the existing, provided tools to very selectively query for a small region of current data from the files on disk. I've run performance tests on this extract operation and it's quite intensive, doing it over a very wide area and number of data points consumes a huge amount of CPU very quickly.

Your reply here is where it all falls apart. I assert that it's non trivial and you come back with a deliberately skewed example saying that AA "Actually is" trivial. You then go on to provide a very visual example that has nothing to do with a direct AA pass. Perhaps you did not deliberately stack the deck but you certainly were not clear or direct in your answers. Something like; "There are very good upscaling algorthims available which can solve this if you have the resources to increase the bitmap size accordingly." would be a far more open answer. I didn't bother to go and google HQ3X, I just looked at your very visual bitmap. A bitmap which is very clearly not a good example of a direct AA pass. There's so many AA algorithms with four-letter-algorithms out there that I didn't even bother looking. All I saw was a very skewed reply.

Here's a bitmap for you, same one I used. 7x7.

Run your upscaling algorithm without changing the size of the bitmap. You'll get something far closer to what I've already posted. Start with a 7x7 bitmap. End with a 7x7 bitmap. Use whatever filter you want. As soon as you want to start tracking the corners of each cloud tile intersection, to smooth your jaggies, you need to multiply the bitmap size by 4. Instantly you're at 28x28. A considerable increase in processing requirement _when looked at as a whole._ For a minor improvement in jaggies. You'd still see it. That was my original argument.

Seems appropriate; We're done here.

You're misrepresenting the size of the storage array. It doesn't matter what algorithm you want to use if there's no massively-bigger amount of storage to upscale into. Your example very deliberately started with a massively oversized storage array (bitmap) showing a crudely upscaled retro bitmap that made no attempt what-so-ever to utilize the capacity it had. Your example did not show a very highly packed data array that would cost large amounts of performance to make bigger. Your example shows a sparsely packed bitmap that is extremely suited to a better upscaling algorithm. Your example is not representative of the data structure that your complaint centers around. Given that you stacked the deck entirely in your favour of course the end result was going to look better. Do you really think that every saw tooth cell of weather in your original complain is full of a 64( 4, 9, 16, 25...) cell matrix of empty data? Boring.

This is an annotated extract from your bitmap. The black pixels are what you selected as your example. The red and green pixels indicate all the wasted space in your example. You have not given a realistic example of what is required to increase the data tracking by a factor of four. Your example is very deliberately misleading. Here is a more honest example of what crude anti-aliasing will do when you DO NOT increase (or waste) the number of cells available to store data in. Example raw data with jaggies. Crude anti aliasing applied without manipulating (or hiding subversively) underlying data resolution. As you can see, the effect is nowhere near as pronounced. Quite frankly I'm insulted by your example above and will not be going out of my way to deal with you again. I hope others will understand my feelings that you deliberately distorted the facts.

You're over simplifying the problem and cherry picking solutions that are irrelevant to the actual problem at hand. This is much closer to 3D texturing than anything remotely approaching retro gaming.

That was a very poorly selected example bitmap that leaves a massive amount of unused room. Play fair.

Sundog Software is very experienced in this domain. They sell an entire array of Weather SDK's. It may sound trivial to just AA a bitmap, but think about it, to have any real effect at reducing the saw tooth the cell data tracking is going to go up by a factor of at least four. If not all you're going to do is end up with blurred data from nearest neighbour cells which gives you the exact same saw tooth cell resolution with weaker weather conditions in each grid position at the fringe.. It's all a trade off... History has shown the commitment to continual product improvement and customer loyalty programs that these products come with... if we can find a way I'm sure you'll hear about it.

Something like this; Except generated dynamically in 3D, on the fly, between whatever cloud structures there are.... are you sure you want to eat that kind of performance penalty?

RWC allows for a much tighter grid of data points. These data points are so small that you can see the cellular structure of the data above. X-Plane has a larger grid and is asking for a more general rendition of "scattered clouds". RWC is attempting to provide precision placement of cell structures over a very wide area that can be flown around. What is essentially needed is some form of 3D volumetric cloud anti aliasing between SMP's already complicated cloud structures. This may seem incredibly simple in theory; "Why the hell can I see blockies!" ... it's actually quite a complex problem when you think about it in the context and detail required above. I hope that helps shed some light on why version 1.x might look a little rough here and there. ( And, also... Frank from Sundog wrote it, not me. So he might just tear my theory down in a few hours. )

If you are unwilling to reduce your options so that you have more VRAM available to avoid fragmentation you are going to have trouble. The new plugins combined allow much more power - but the power is in your hands. Please try reducing your options so that more VRAM is left available. You are down to about 10% free. Please imagine how this 10% free gets very thinly spread after hours of flying, as per this diagram; Eventually something tries to load that is too big to fit in any of the tiny fragmented slots of VRAM you have left and - BOOM - your driver crashes. You have the power to reduce the VRAM load. Please try it.

At the moment the only source of WX radar data is X-Planes built in glass panel display. The X-Plane WX Radar data is filtered using various drawing techniques to provide a more authentic data display. I believe Nils is responsible for the IXEG radar systems so I can't comment on exactly what is going on but he's put in a lot of work to make it special for you. I'm pretty sure you can see a bunch of the effects in some of the published videos.

X-Plane provides a mechanism we can use to disable all forms of built-in cloud drawing and generation automatically. You do not need to do this manually if you're using X-Plane 10.30 or better. From the developer guide; "overrides building and drawing of clouds as well as white-out-in-cloud effects" If in doubt, double check the manual.

You're probably loading up your VRAM too heavily and experiencing a crash after long term fragmentation that it can not recover from because you have left it such a small margin to work with.

Please keep this in mind too; 300 mb of VRAM in one huge chunk is much more useful than 300 x 1 megabyte chunks.

Not at this time. Given the nature of the teams under the X-Aviation banner we'll be looking into ways to make this happen.

This is a non-issue if you take the time to contact X-Aviation support and explain your requirements. Increasing the license limitation from three to four is simple.