Hello,

 

Why are there two regionsof graphic details in XPX?  As you can see in the attached picture.  I set the world detail distance to be very high.

 

Thanks

 

 

That's unfortunately a know issue in high altitudes :(

Yes this is an issue that eventually should be fixed, that and the fog/cloud transition, among others of course.

should be fixed

That worries me.  LR IMHO has to fix this.  Is it on the fix list anywhere?

 

Also when you said that this is a high altitude problem only, at what altitude does the problem manifest itself?

 

Thanks

That worries me.  LR IMHO has to fix this.  Is it on the fix list anywhere?

 

Also when you said that this is a high altitude problem only, at what altitude does the problem manifest itself?

 

Thanks

I know that Ben did mention they had an idea on how to fix it. I wouldn't worry, it will get fix.

 

I think above 18k feet.

It comes to play whenever you are at such an altitude that you can see the borders of the tile region you're flying in.

 

X-Plane's scenery calculations / display are tile-based. It caclculates each and every object in the tile region, a "neighborwood of tiles", arround the one you're ober at the moment, which hsppend to be the region you can see displayed on the Map view when you start zooming out...

 

Since it calculates everything there, in order not to got OOM, it blurrs beyond it :-/

 

There is nothing wrong, in principle, with this approach, and I find it a much better approach than the one followed, for instance, in MSFS.

 

I am again using FSX primarilly, and enjoying the great PMDG 777 and A2A's C172, with total smoothess, up to a 10 hr flight! but this is because I use no add-on scenery other than LPMA and Lukla. MSFS causes OOMs when you fly over a series of areas covered by detailled scenery because, contrarily to X-Plane, it cashes everything it overflies within a given range.

 

In X-Plane they could probably:

 

1) Only display / calculate scenery elements within a plausible distance, depending on type ( does it make sense to calculate / render buildings or roads that are 80 NM away???).

 

2) Not blurr distant scenery

 

3) Take care to processe each and every navaid ( btw using a proper algorithm to calculate the range of VOR / DMEs wih altitude...) even if they're out of the tilkes region being covered

 

4) Allow the Map view to display info beyond the current tile region. It's very annoying the way it is right now :-/

 

Not a very technical explanation I know.

 

 

Let's hope this really get's fixed :-/

Well, I try to shed some technical light on what is happening ... some infos are already more or less correct, but there are some technical reasons for what you are seeing (and what could be done).

1. Yes, its correct, that X-plane works on a tile-by-tile basis. Internally its called "scenery shift" ... Thats when new 1x1 degree tiles (a whole new DSFs) get loaded and old one are removed from memory. At the moment X-Plane always has 3x2 tiles loaded (3 is horizontal, 2 is vertical axis). This sets the current hard limit on how far out you can see detailed scenery.
2. The blurred landscape is NOT scenery in the classical sense. So, there is not scenery which get blurred .... But instead its a completely different layer of data. Effectively it is the orbital textures (which you see as the whole planet when you zoom out far enough) which in their alpha mask have a "per pixel" elevation value. This way the sim can give those points a height .... effectively it translates the orbital textures into a very very rough triangle mesh (its resolution is limtied by the res of these textures) which is - via the elevation info for the pixels - transformed in a very rough elevation mesh. The blurriness of the texture comes because its very low res, and to not make it look like gigantic block, they are softened by some classic blurring filter ...
3. But I repeat, its not standard DSF tiles which get blurred, but effectively a very low res, planetary triangle mesh ... If you don't blur it, then instead you see big, rectangular blocks (like when you zoom in to close on a photograph).

Then to the solution part:

1. Load more DSF tiles (like 4x3) ... this was not possible with 32bit X-Plane, but might be possible now with 64bit X-Plane, and to my knowledge this is the way which Laminar is researching ... The problem still is, that you need to load all the extra DSFs (which don't tend to be small and very heavy on pure data), keep them in memory, manage them. And of course it makes sense to strip out unnecessary data in the distance (effectively you don#t want anything else than the textured mesh). The optimal solution would be, if there would be a way to only load the mesh part of distant DSFs, and leave out all the rest (like roads, forests, city zoning) ... and only load it alter when the DSF tile comes close enough. BUT, I can't say if this is technically possible or not (Ben Supnik ist the one who can tell). ..... In the most ideal world, it would be nice, if even the triangle mesh density could be lowered far far in the distance ... but I am afraid, that this is algorithmically non trivial either (and storing additional, low res mesh in the scenery would make the DSFs even larger).
2. Have an intermediate layer of "scenery tiles", which are lower res (and possibly only mesh info) than the standard DSFs but higher res than the orbital textures .... Again, the problem is quite a lot of extra scenery data on disk (and to distribute) .... could be easily 10 GBytes or more (just making an educated guess here).
3. Make the orbital texture higher res ... This would be a possible solution too. It wouldn't make the distant scenery blur free, but for example by increasing its res 4-times (along each axis) might increase the situation quite a bit (to almost acceptable I think). BUT here again, data volume comes in play .... currently the orbital textures are about a  GByte (again guessing as I not have my sim at hand at the moment, but this was the figure approximately) ??? So, upping the res by 4 along each axis would mean that its size would go up 16-times (to 16 GBytes) .... again, not too shabby.

So, there are quite a few possible approaches to this problem (to fill the gap in the distance and the really really far distance), but none of them is trivial or cheap to achieve ... and each has its pros and cons. The reason why FSX can do this a little bit - in it own way - better is, because it generates the entire scenery - more or less - "on the fly" out of half-raw data ... thus it can load less half-raw data and generate less detailed scenery out of it in the distance ... Whereas X-Planes Scenery tiles are far more "complete" and ready to visualize .... but much harder to easily scale down afterwards. Both approaches have their pros and cons ....

Make the orbital texture higher res ... This would be a possible solution too. It wouldn't make the distant scenery blur free, but for example by increasing its res 4-times (along each axis) might increase the situation quite a bit (to almost acceptable I think).

So if I read this correctly and buy this package:

 

http://secure.simmarket.com/taburet-xporbit-for-x-plane-10.phtml

 

Also this is from Taburet:

 

"We DO NOT Reccomend this package to those who like to fly over 300.000 ft altitude- as the textures resolution has been raised considerably compare to default stock scenery - but very much ideal for any kind"  

 

Can anybody sheds some light over what he meant by "fly over 300.000 ft altitude"  was that 300 thousand ft?  Is he talking about the space shuttle?

 

It will solve the blurries?

 

Thanks

Well, it only partially solves the "blurries" .... there are quite a few screenshots there, and on some of them you see whats up:

http://secure.simmarket.com/images/products/3/33/6938/98954_C-130_17.jpg

 

Judging from the download size, he has maybe (at maximum) doubled the resolution on each axis (maybe only one axis?) .... so, it improves the situation, yes, but does not entirely solve it (in the way you might hope it).

 

One more difference might be, that his orbital textures are derived from real space images (maybe "blue marble" or something like that), while the default orbital textures are generated by taking a "picture" of each DSF ... so - at least in theory - the original orbital textures are much closer - color vise - the the default DSFs (the idea is, to make for a less seamless transition ... but of course, this is limited by the "low" resolution already).

Andras,

 

thank you for your comprehensive answers!

 

Let's hope for the fix, and hope it doesn't come in so many bytes...

 

 

One more difference might be, that his orbital textures are derived from real space images (maybe "blue marble" or something like that), while the default orbital textures are generated by taking a "picture" of each DSF

I took a chance and bought the package anyway.  I am happy to report that the package has individual DSF files and the blurriness although still there is much more tolerable at least now there is a seamless transition not almost disjoint like my screen capture above showed.