active True Earth South strange white grids in 10.5

[Splendiddd]

Hello,

 

I know there is limited support for the vulkan beta of xplane but i have to report this i think?

 

I have TE south and i noticed a white grid sort of snowy pattern on the textures (Capture1)

 

I purchased Southhampten airport and installed it and you can clearly see the diference from the airport textures to the region Orbx textures.

 

Capture 2 is Vulkan (as is capture 1) and i also tried to do the same sort of capture of the openGL version witch look normal (Captureopengl)

 

I have to note that the opengl version is a seperate install of xplane.

I aslo profided my scenery.ini

 

Any ideas? seems that the airport work fine in vulkan, i also noticed it only in TE south and not in LOWI, Londen City, edinbrough and the florida region witch i also own.

 

Thanks

 

Regards, Rob

scenery_packs.ini

[Jon Clarke]

I also have the spotted appearance as you can see in my pic attached.  Maybe @Tony Wroblewski could comment. It looks like a massive over-decal anomaly. My pic is near EGBS in TEGB South

I have rearranged slightly your scenery_packs as you had a few entries incorrectly layered. scenery_packs.ini

 

 

 

[cbcdesign]

The same decal issue affects 11.41 too, some of us can see them others cannot so its not just in 11.50 although that does show the issue in a more pronounced manner.

 

An option to take decals out of the scenery would be nice. We do not have them in the North UK edition and it looks much better and more natural as a result.

It would solve the issue shown in the image below and this is in XP11.41 too, not 11.50.

[John90]

Hello,

This problem does seem more pronounced in Vulkan however its always been there for myself at least.  I prefer to have the decals so when I bought true earth north I ended up adding them myself using a free tool. I experimented with the variety of decals that are available and it seems that the finer grained decals make the problem less noticeable. 

 

Attached are previews from the "apply decal" tool. The first is the same or similar to What Orbx applied in TE South. The second shows one of the finer grained example's that people might prefer.  The best outcome would be that Orbx to offer the option to switch them completely off, or give the option to select from the variety of decals. 

[Trustdesa]

Could easily be something related on how Vulkan is working on Texture, IMHO... however not only it is a beta but a very early stage of a big beta process, it is like trying to find a particular grain of sand on a beach... 

 

@John90 I like decals too however thinking of performance...

 

From Ben Supnik @ Lamninar.

Quote

One thing I have learned during my time here in the matrix is that users often find new bugs to be significantly more annoying than existing ones; trading an existing bug for a new one is often seen as a big step backward, even if the new bug isn’t that bad. I think this is just human nature – we get used to things – it’s what humans do – and this takes the sting off of some bugs that have been around a while.

I bring this up to put in context the problem of texture paging, blurry textures, and VRAM management in 11.50. To understand what makes VRAM paging hard, you have to understand how the OpenGL driver solved the problem, and ask yourself: what was the old bug, what is the new bug?

What Is Texture Paging?

Texture paging is when textures are moved between the memory on your graphics card (VRAM) and the memory in your computer (“system memory”). At any given time, X-Plane may have more textures loaded than you can fit on your card, but it doesn’t need them all at once. As you fly, different textures are needed, and the textures have to be moved around.

If this sounds a lot like moving data from RAM to your hard drive (virtual memory), it is. When I get the question “how can X-Plane be using 2.5 GB of texture memory when I only have a 2 GB card” the answer is…texture paging.

How Did the OpenGL Driver Do It?

In an OpenGL based app, paging textures to VRAM and back is entirely up to the OpenGL driver. The algorithm goes something like this:

1. Start drawing.
2. Realize something you need is in system memory.
3. Move something you haven’t used in a while out of VRAM.
4. Move the thing you need into VRAM.
5. Continue drawing.

The OpenGL driver pages during drawing when we need something new, and the result is a stutter – the frame takes longer because it cannot be completed until the texture is moved to VRAM.

Now NVidia, AMD, and Apple have spent a lot of time and effort to make this work as well as they possibly can, and I’m definitely selling short the complexity and sophistication of the drivers as they try to guess really well what should be moved out of VRAM. Still, two key facts will be true:

1. If we need to page stuff into VRAM to draw, and we don’t figure that out until right when we need it, there’s going to be a stutter. Maybe a really short one you barely notice, maybe a really bad one, it’s a question of “how much”, not “if”.
2. What you see on screen always looks fantastic – never blurry – because the driver won’t cut resolution to save VRAM.

So…the old bug in this case is stutters due to VRAM containing the wrong stuff.

How Does X-Plane 11.50 Do It?

With Metal and Vulkan, it’s up to us, the app, to decide what goes in VRAM and what doesn’t, and to schedule the movement of data between VRAM and system memory. Our strategy is:

1. Keep an eye on how much memory is free.
2. If it looks like it’s getting too close to full, shrink textures to a smaller size. Prefer to shrink textures you’re not looking at. Do the shrinking in the background.
3. If it looks like VRAM has empty space free, grow textures, preferring ones you are looking at now. Do the growing in the background.
4. If we have to load new textures in the background (e.g. new DSFs as you fly), wait until old textures can be shrunk.

We have a huge advantage over the drivers in this game: we know the textures we might need in the future, long before we actually need them. We can also shrink textures. This means we don’t have to stop and shuffle things around, and that means we can avoid stutters. So we can fix the old bug: stutters while you fly.

(To be clear: this is not the only source of in-flight stutters while you fly – OpenGL and 11.41 are full of them.)

The down-side is: if VRAM gets tight, we’ve made some of the textures lower resolution. This is a new behavior (blurry textures), so my fear is: users aren’t going to like it.

In particular, the OpenGL driver uses the exact optimal set of textures for every single frame – at the cost of stuttering. We may not have things shrunk and grown in exactly the best way while you fly, so for the same VRAM and no stutters, we may not be as visually sharp.