RWC and cloud coverage shape

[Ben Russell]

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.

[Havner]

3 minutes ago, Ben Russell said:

You have not given a realistic example of what is required to increase the data tracking by a factor of your.

I didn't mean to give an example to increase the data specifically by _four_.
I just pointed a general algorithm.

3 minutes ago, Ben Russell said:

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.

I explicitly stated that the data after being treated with something like HQ3X _will_ be at higher resolution. That's the whole point.

3 minutes ago, Ben Russell said:

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.

And I am being treated as a negative here? Wow...

Sorry sir, that you are being insulted by telling you about HQ3X in a civilized manner.

I did not distort any facts, maybe you misunderstood me. I didn't mean to imply that a simple AA algorithm without increasing the resolution would help. Of course it wouldn't. What I meant is that dealing with an aliasing problem (e.g. that comes from METAR data) by using some specialized algorithm and increasing the grid resolution would. I think that's fairly obvious that HQ3X is not an antialiasing in normal sense. By definition it is an upscaling algorithm. But it obviously deals with an aliasing problem.

[Ben Russell]

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.

[Ben Russell]

Seems appropriate;

 

We're done here.

[Havner]

12 minutes ago, Ben Russell said:

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.

This was just an example with an image I found. Should I have scaled the pre-algorithm bitmap down (to its original size) so it would pack one "visible" pixel to one pixel of an array to make you happy? This was a simple conceptual demonstration of what this _upscaling_ algorithm does. Without taking care of any storage data. The images have been rescaled to be visible. Simple as that.

You are over interpreting it.

Edited April 16, 2016 by Havner

[Ben Russell]

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. 

 

[Ben Russell]

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

[Havner]

6 minutes ago, Ben Russell said:

Run your upscaling algorithm without changing the size of the bitmap.

What? Upscaling does change the size. That's why it's called upscaling.

Quote

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.

Of course you will.

Quote

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.

And that's true as well. You're saying what I said few posts before.

Upscaling -> bigger resolution -> not sure SMP can handle that.

Edited April 16, 2016 by Havner

[Ben Russell]

1 hour ago, Havner said:

In terms of dealing with the edges it actually is. There are very good algorithms to deal with this particular issue. Like HQ3X:

(Images courtesy of Wikipedia)

 

 

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.

 

[Havner]

32 minutes ago, Ben Russell said:

I assert that it's non trivial and you come back with a deliberately skewed example saying that AA "Actually is" trivial.

Handling the bitmap itself (whether this is a simple AA or an upscale) is actually trivial. SMP tracking that data might not be.

And you said that first and I agreed with you. Here, in the very same post you quoted.

You: 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.
Me: Yes, this might be an issue. That's why I wrote it might be down to SMP not being able to actually process such a high resolution map.

Quote

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.

Maybe it would, but with me using words like "upscaling" and "SMP might not be able to handle this" it's actually clearly implied. And I assumed it was clear.

Quote

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.

Sorry, I was talking to a fellow programmer and I did use word "upscaling". I thought that must have been clear to you. With a bitmap as a simple (not scientific "white paper" style) example.

Now, can we sincerely smile and move on? Because it seems we agree on everything and the pictorial you posted actually seems to refer you more. You said twice already you're done talking with me and yet you still argue about a non issue

Best regards

 

Edited April 16, 2016 by Havner

[Ben Russell]

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.

[Havner]

11 minutes ago, Ben Russell said:

I feel it's important not to trivialise that. For the entire audience we deal with. Sometimes that means a few extra words.

I never trivialize anything like that. I know how that stuff works from the inside very well. I'm just very direct and people don't seem to like that (sometimes understandably). But I do talk merit. At least I very much try to.

Quote

It's also frustrating that the number one issue we're hitting at the moment is VRAM fragmentation due to VRAM pressure.

I had this as well. There is a long post here about the issue in 3.1 where you increase the cloud coverage. I hit this limit, but after reading it and understanding what is going on (I too had abrupt and _severe_ drops of FPS without any particular reason) I limited the general X-Plane size of textures from "Extreme" to "Very High" (I have 3GB VRAM) and it helped. It relieved I think 300-500MB of VRAM and now I can fly with 10000 sq. m. area of clouds.

Edited April 16, 2016 by Havner

[Jakob Ludwig]

Reducing the texture resolution one notch down helped me a lot as well. Now even the small pauses on weather changes disappeared. Took a bit of Investigation, but at the end it increased the simulation experience to the better, sacrificing only little at the visuals.