X-Plane 10.40 will have an option to load a larger local region of DSF scenery. For as long as I have been involved in X-Plane (back to X-Plane 6 as a user) the local scenery region was 3×2 tiles (each 1×1 degree in latitude and longitude). With this option, the region is 4×3.
What this gets us is the option for a longer viewing distance before we have to transition from the higher detail DSF scenery tiles to the lower resolution whole-planet render. In X-plane 10 the planet render actually has shape, but the resolution is low; if you see it up close, it does not look good.
Some fine print:
- You will only be able to use this option in the 64-bit build of X-Plane. The 32-bit version does not have enough memory.
- Combining extended DSFs with heavy third party scenery may be unacceptably slow. For example, Alpilotx was able to run extended DSFs with the HD meshes, but his computer has monstrous amounts of RAM (64 GB I think??). I’m pretty sure extending with the UHD meshes is a non-starter.
- Load time shouldn’t be too bad; this change also includes a re-work of the DSF loader that takes better advantage of multi-core hardware. If you have a 4-core machine your DSF load time shouldn’t be worse, even with extended DSFs.
Here are two sets of pictures taken over the demo area at extreme res on my PC; this shows the interaction between atmospheric scattering and loading more DSFs. The camera is at about 30k feet.
The combination of pushing the transition to the planet “out” away from us and using scattering to remove color detail starts to get something that looks more like the real world.
Note that to get the match-up in the lower right, you must have Earth Orbit textures (which come with any full install) and you must be in extreme res or the planet starts to get fuzzier.
Here’s another set.
In the long long term, I expect the planet to improve in render quality (with at least a 2x boost in image quality, and perhaps better than that in mesh shape), and I expect scattering and other lighting to improve in quality.
I do not expect to further extend the DSF box beyond 4×3; I think that the planet can improve to further “bridge the gap.”
Freaking YAY!!! 🙂
Thanks, Ben. Time to go buy another 56gb of RAM. 😉
Addendum: If one is flying high, then the HD meshes are of less value, except in cases where the OSM data for water is better. So if one is flying low level, use HD. If flying high level, temporarily disable the HD meshes in the scenery_packs.ini file with SCENERY_PACK_DISABLED, and don’t select the extended visibility option.
Request/Suggestion: Not to cost you more hair from your head, Ben, but how amenable would the new features be to accessing via dataref, so that the options for scattering and distance could be selected on the fly? If flying at low level, clearly system resources could be freed up since viewing the additional real estate might not be necessary.
The DSF distance is _private_-data-ref accessible because most of the datarefs are.
It sounds like something one would not normally be aware of.
After thinking about various plugin scenarios that could modulate resource use, it did occur to me that one might end up with a bit of an adverse loading situation if transitioning to or from high resolution scenery and/or the new DSF load feature.
The trick for the user, then, is to plan their distance rendering options and their HD scenery options before beginning a flight — literally before even starting X-Plane. Maybe some sort of stand alone application could be created instead for “pre-initializing” these options… but that’s something an enterprising user would generate, not necessarily LR.
Again, thanks. I think a lot of users are really going to like this, especially the heavy metal flyers.
My own view (as a user/sim pilot) is that changing rendering settings during flight isn’t “worth it” in terms of the hassle and lack of immersion due to having to manage x-plane and not the flight deck. But this is just my opinion.
As a developer, I’d like to see an engine where -no- setting changes are necessary. But there’s no question that we are not at a point where computers are sooooo fast that we can afford to just leave everything on all of the time and there are no trade-offs.
Very Cool ! Can we have the beta now !
“planet to improve in render quality, and I expect scattering and other lighting” Will this be in the 10 run or 11 run ?
Regards……..
Only one thing will be worse in 10.40. It is a lack of desire to execute the command ‘descent and maintain FL…’. FL300 with extended DSF + scattering just GREAT.
Curious why it’s a rectangle (3×2)? Why not generate 0.5 degree lat x lon and then load 4×4 (or 8×8 in 64 bit)? I can see the tiles being geometric rectangles moving towards the poles, but near the equator, they are still squares…aren’t they?
It’s 3×2 because on average the tiles (which are 1×1 degree lat/lon) are taller north-south than they are wide east-west in actual meters. So the 3×2 is a constant “approximation” to avoid getting a very ‘skinny’ DSF loading box in northern regions.
The tiles were 1×1 long before I worked on X-Plane; the size didn’t pose an engineering problem, so I never tried to change it. (A transition would be somewhat complex.)
This feature isn’t in the 10.40 alpha 2 trial is it ? i just took a spin up to 30k ft and it does not look like your images
No it is not. Only the features listed in Austin’s alpha release notes are in Austin’s alpha.
10.40 alpha 2?
I’m testing alpha 1 but I’m not aware alpha 2 is already available, or it was a typo (alpha 1)?
@Ben: can’t wait to test the long distance, I built my rig with 32Gb because this option so that ram is eagerly awaiting for this since then!
Well, I think, that people with 32 GB of RAM should be able to run even UHD Mesh (at least if their GPU can handle it!) … and HD Mesh Scenery v3 should be usable (depending on the region) even on 16 GB RAM.
BUT, if someone uses OSM based scenery (especially w2xp based stuff) the RAM demand can be much higher. So … in the end you will need to test and see which scenery you can use while also relying on long distance view.
Hopefully this comes true, because IMACS does´t go farther than 32GB of RAM… thanks a lot for this Ben, will be waiting for the beta!!!
The UHD meshes don’t take that much RAM anyway, with w2xp max details flying at 7000ft around the alps, ram usage hovers around 12GB.
I am supprised and exited all rolled up in one.. But I am aslo very sceptical when it comes to performance. One thing X-Plane has going for it is the good overall performance, normally with my render setup It varies between 40-50 steady. But then again I do not have much scenery installed either, normally I do not install the whole world due to me flying most often just in Norway. Anyway, with UHD by AlpilotX and his new HD Mesh v3 the loading time was extended pretty much. I fear that with this extended view we would now feel the impact on both sides, FPS and loading time.
PS.. Did I mention that my render setting now is High for distance view
I *completely* agree with you, although I’m actually writing this from your fellow neighbour in east, Sweden. As if that would be relevant, but okay. I agree with you and really encourage Ben to think again. We should definitely stop defining what is leading edge simulation realism, stop updating and redoing ourselves in an effort to get better at things, to reach further, to make more immense impressions. We should be glad of the impact current day simulators give us and personally I could not agree with you more on thinking that X-plane, even 10 or 20 years from now, absolutely should and *must* be optimised for current day i7s and GTX980. After all, we invest these amounts of money on hardware..!? It would be utterly disrespectful of the very grounds of these things called human innovation and technological progress to try aiming further and actually trying to get things to work better, with more immense results, at lower costs, and for better overall end effect.
Why oh why can we never just realise that we do not need better graphics cards than GTX980 and 8GB of ram? Thats.. like MONSTROUS amounts of ram? You know, 20 years ago, I had like 8MB, and I still was a happy boy?
Tom: It lies in human nature to evolve and nowadays make constant industrial progress, ever making things working more efficient and creating more beautiful end results. X-plane is a beautiful piece of work, and personally I have been a X-plane user and follower since 2002. Ben, Andras, that italian artist, Austin and all other who make this work are nothing else than heroes in this industry. What would be without X-plane and the incredible new innovations and developments these people do to further push the immersion? You know how hard it is to code AI and algorithms to actually mimic a real world scene? Now take the concept of the idea and apply it on every meter of the world.
I really just follow this blog passively but comments like these just make me mad. No argument can stop the push in advancement regarding computer hardware and virtual immersion. It is just disrespectful to try convincing bleeding edge code writers to try holding on to *what we got now*, argumenting that *this really is enough*. You know in 25 years people will debate things just the way you are right now. They will keep stupidifying others, argumenting that 8K looks *so* good and that 16K really should not make any sense. After all, the step from 4K to 8K was a huge step in image quality, why would we need 16K?? And this covers the amount of ram too. 5 years earlier we will have just 512GB of ram and everything just worked like a charm then – why are people talking about 1TB?? I mean, 20 years ago, people had that capacity in their ssds. Thats just nuts. Can we not just at some moment in time just stop the development in computer advancement, and just hang along, being for ever satisfied with status quo?
People like you will for ever exist, and will be a reminder of how fast a pace we are going regarding technology. It *is* in fact hard to keep updated with all the new innovations technology brings and how all these things should be incorporated in our lives. Just take the concept of smart watches. This is a completely new market segment, that no one for real could visualise be commonplace today, 10 years ago.
Next time you read about technological progress, just look upon it as a result of the beings we are, and the achievements we constantly try to strive forward for. No single person should ever blame you for running X-plane 10.40 final at 1024×768 with everything at low and with clouds at -1 cloud puffs on your autumn 2003 iMac. But if you want to take in, enjoy and be part of bleeding edge technological progress in the field of computer software, you *need* to keep a more optimistic and humble tone here. And buy a new graphics card eventually. The world constantly turns around its axis. And you, as well as all we other around you, in turn – move along as well. Don’t stop.
Kom Tnudsen, I’d have to say that I think your reply was a -liiiiittle- bit over the top for Tom Knudsen’s original post. But I appreciate that it was devoid of the F-bomb. 🙂
I am actually quite sympathetic to the real Tom Knudsen’s concern – the norm among our users (whether I like it or not) is to expect that today’s top end hardware will be able to run today’s simulator at its top settings. If I had a nickel for every user who has asked us “what hardware must I buy to run X-plane at max settings”, I could corner the nickel market.
I am also unsympathetic because HD and UHD meshes are a third party add-on and there is no way that we can ensure that a top-end machine can run with top-end settings when one of the variables (mesh density) is raised in weight by a third party add-on. The same thing applies for very complicated or detailed aircraft. Tom may have to pick between UHD meshes, more visibility, or spending money on more hardware. If he picks to not use extended visibility then it’s as if the feature doesn’t exist, so I say no harm no foul.
already made my week 😀
Thanks for the heads up!
I saw you mentioned scattering as something that will change in the long-term , so I wonder does that mean those scattering data refs that every body edits now , aren’t going to change soon (or at least stay the same in 10.40) ?
Also , will the new fog code will make it to 10.40?
The code that you see in these screen-shots is scheduled for X-Plane 10.40.
There are no changes to the private atmospheric scattering datarefs in 10.40; of course they are private data refs and not at all guaranteed to be stable.
I think the scattering looks good and I’m glad it’s coming in as a standard feature. Some of the 3rd party plugins like RealTerraHaze also allow for making the night lights a bit more “bloomy”. Is there any plan to do anything with the lights?
I know of course there is no perfect solution for night light size/bloom/brightness – a computer monitor simply doesn’t have anywhere near the dynamic range to show the brilliance of runway lights against the darkness of the background. I think the X-Plane default lights at the moment are a touch too subtle but some of the effects with 3rd party add-ons are way over the top. I guess it’s a difficult thing to get right, but as different monitors have different capabilities in terms of brightness and contrast, is this not something that the user should have some control over?
I do have a bug filed to try to calibrate the lights better at some point.
I am _not_ in favor of user control over the lights…my personal view is that X-Plane already has way too many rendering settings, and it’s my job to make X-Plane look good, always. If X-Plane isn’t doing that, I need to fix X-Plane, rather than add a rendering setting that 3% of users will understand and 97% will set randomly.
If you’re on this blog commenting on these things, you might be in the 3%. You can always hack up settings.txt if you -really- want to take the red pill and see how far down the rabbit hole goes… 🙂
Does this mean you didn’t make it to Germany ?
No – I am in Germany right now!
Very much looking forward to this. Do you have any prediction when the 10.40 beta will be available? are we talking about days, weeks, months (hopefully not years ;-))?
I also wonder if this change has an impact on the gpu memory usage as well. What graphics card was used for the screenshots you showed?
No predictions on timing.
The change to GPU memory should be pretty minimal — we’re not loading more textures or anything. Those shots were taken on an AMD 7970; I have no idea how much VRAM it has, but it’s almost certainly at least 2 GB – it was a top-end gamers card when I got it (several years ago).
Can I ask what thoughts have been had towards supporting different levels-of-detail (lod’s)?
It seems the world loves Andras’ hd scenery, but a lot of people will have to compromise between close-up detail and long-distance detail, if turning on the 4×3 tiling kills their system. Just from a processing point of view, trying to deal with hd mesh that’s far away seems like a waste of computing power.
So you have the base mesh, that is replaced by the hd mesh (and is then pretty much redundant on your disk). And there is the world mesh, super low res, used to render the distance.
What’s the scope for using a 3rd mesh that sits between the two?
Or using the base mesh for the further tiles, only the hd mesh for what’s under you?
Or making the world mesh a lot higher resolution and breaking that down into tiles too?
Just wondering what you guys have considered and dismissed (or decided was way too big of a refactor!)
Honestly, I do not have a plan to try to support super-HD meshes like Andras’ as part of the LOD scheme. Andras dreamed up and created this scenery himself by cranking up the settings for mesh generation.
In the long term, I expect to handle the wide range of LOD we need via hardware tessellation. Once hw tessellation can be used (and this is a ways off) we will get our detail by having X-Plane dynamically show more of the raw DEM data, without the need for an ultra-high-density mesh. The result will be a lot less cost to the tiles when they’re far away.
The same logic goes for the planet; it can be higher res if we can use tessellation to vary the drawn output dynamically.
So my expectation is to invest effort in tessellation rather than trying to provide an intermediate bridge between UHD tiles and the planet.
Great news! We have something to pester you about after 10.40! 😉 Seriously, though — not nailing this to the ground or anything, but do you anticipate that you’ll be able to include hardware tessellation at some point in the 10.xx run, or is this feature even further down the road?
There are many things lots of users want to see attended to in X-Plane. But IMNSHO, the ability to “see forever” is one of the things that makes flying so appealing, and view distance tweaks like you’re working on now are going to be like putting on corrective lenses for the first time and seeing the distant world in far better focus. It’s going to be liberating, if you’ll pardon the dramatic turn of phrase.
I’m not supposed to go around talking about 10.xx vs some future version of X-plane whose number is larger than 10, but I am pretty sure that tessellation is not coming in the v10 run.
For now the ‘more DSFs’ trick is the only card we can play in the short term. Honestly, we would have played it before but we needed to get to 64-bit to be able to have that many DSFs in memory at once. We’ve intended more DSFs since 10.0 and we prototyped the scenery with it to see what it would look like.
Fair enough. I promise not to tell anyone you told me, and my lips are sealed!
Thanks. Enjoy the German brewskies!
“In the long term, I expect to handle the wide range of LOD we need via hardware tessellation. Once hw tessellation can be used (and this is a ways off) we will get our detail by having X-Plane dynamically show more of the raw DEM data, without the need for an ultra-high-density mesh. The result will be a lot less cost to the tiles when they’re far away.”
Best news I have heard in a long long time…
Hi Ben,
sounds great! Is it correct when assuming that when you change the tile size from 1×1 to 3×2 also the openGL coordinate system will shift all 3×2 then?
Thanks for some feedback…
Markus
First, I think you are quite confused about what happened.
– The tile size has been 1×1 degree for 15+ years and is not changing!-
– The GRID of loaded tiles can optionally be grown to 4×3 from 3×2.
– The OpenGL coordinate system that any add-on can see is still based on the center of that box, whether it is 4×3 or 3×2.
– The center of the box is always shifted to near the aircraft.
So while the “edge” of the DSF box is more sloped (in cartesian coordinate terms) you can’t really fly there because it will just keep shifting.
Now internally, in v10 we moved from one big coordinate system to each DSF having its own -internal- coordinate system – centered at the center of that single tile. So no change was needed for the number of tiles increasing. This change to center-of-tile was done so that we wouldn’t have to rotate the autogen (in 3-d space) at scenery shift time; rotating the autogen was already slow in v9 but would have been much worse in v10 with the new, more complex autogen.
But this “DSF-center” coordinate system is never exposed to any add-on.
What will be the impact on photographic scenery (e.g. simheaven ZL17)?
If photo-scenery uses LOAD_CENTER directives in their .ter files (which they all should!!!!) then the impact should be minimal, because the ortho-imagery for hte “far” tiles will be at its lowest possible resolution, and will be paged up as it gets closer.
The cost in RAM use for the mesh is a function of mesh density if it’s like our default meshes it’ll be fine, if it’s heavy like UHD, then going to ‘more’ DSFs will significantly increase the RAM you need. I am not familiar with SimHeaven’s authoring techniques so I cannot comment specifically.
From the moment of my entrance to X-Plane (mid-v9) the restriction of visual dsf’s was my main concern, and yes I have shouted loudly in this area because I thought it was the biggest turnoff for current and new users for the simulator. Certainly it is the biggest visual issue for the long haulers. I understand how the X-Plane scenery system works, but I couldn’t understand that once above 13,000ft or certainly 25,000ft my frame rate is in the 50’s bracket but the visual imagery was so average.
I do like Ben Supnik, do not like changing my resolution settings just to compensate for the differences in altitude. but as the ground requirement restrictions are minimal above that certain line of altitude then why can’t the system just adjust for that?
Hopefully here in 10.40 is at least a big part of that restriction is now lifted, and no doubt this which is the one of the biggest turnoffs to the simulator will make X-Plane a much more mature simulator than it looked before SD
Hi Ben, this is a good news but like anothers user i llitle concerned about the impact this may have in performance of the sim.
Could make a configuration option choosable from the Render Setings to enable or disable this? This could help users having who have a small / medium system. or mayble can be directly involved with the option “world detail distance” ?
Generally the screen and the idea are very well.
Thank you!
Yes – “extended DSFs” is _optional_.
It is optional because some users would have to DROP the UHD meshes if they use it, and I don’t want to force anyone into a hardware upgrade in a free update.
Sorry if this wasn’t clear from the beginning – maybe I forgot to write this in the post? 🙁
So what would be the bare minimum ammount of RAM required for the extended DSF sitched on with the standard mesh of the Global Scenery? I only have 8 gb of system RAM with a GTX 660 with 2 gb of VRAM. Thanks!
I don’t know – I would expect it will work with 8 GB but it depends on what else you run (e.g. 3rd party airplane, other add-ons, XSquawkBox, texture res setting).
Very much looking forward to this, I hope there will be an early 10.40 beta so people can test for themselves different ram/scenery scenarios. What a great improvement, many thanks.