I was going to write this post yesterday, and I’m glad I didn’t, because my estimated release time was off by a day. But 10.30 is now cut and is being mirrored out to our servers. If things go without hitch, we can hit “go” tomorrow.
In the meantime, you can read about what we did here – after a little bit of cleanup I was able to cut the notes down to ten pages. Aircraft authors, you’ll want to read the docs on the new GPS and other cockpit issues.
(10.30 is probably better documented as an early beta than any previous beta we have done, both in terms of completeness and detail of changes and release notes, and in terms of new docs on new features.)
Perhaps I am too optimistic, but: rendering solid, opaque objects that look realistic in real-time (read: for games and rendering engines) is rapidly becoming a solved problem. I look at the bleeding edge of the top-tier shooters as a preview of the direction for the field of real-time rendering*, and for the last year, physically based rendering (PBR) has been front and center.
I’ll write more about PBR in another post, but the short version is that, in PBR, the equations for light interacting with materials in a rendering engine are modeled more closely on real-world physical equations; the goal is something that is very accurate to real world optics, and produces realistic results over its entire range of inputs.
PBR is made possible by increased computing power on the GPU. (And here when I say computing power I really do mean computing, or ALU power; PBR requires more math per pixel to calculate for a wider range of optical effects, often with more expensive but better approximations of the underlying optics.) We now have big enough GPUs to do “real physics” (well, real-ish) when it comes to light and solid objects. This is a huge step forward when you consider that a decade ago, calculating lighting equations per-pixel was marginal and had to be done in the wrong color space for speed.**
So for solid objects like airplane fuselages, runways, buildings, baggage trucks, etc., we have physics.
Then there are clouds, and the air, and rain and fog. For those we have magic.
By magic, I do not mean something truly magical, something outside the realm of what is possible with computer graphics. Rather, I mean the definition a professional magician like Penn Jilette might use: trickery. To quote Penn***:
The only secret in magic, there’s only one, and that is, the secret must be ugly. You cannot have a beautiful secret…So, in magic, what you want is an idea that is not beautiful…If I have to say, he’s lying about that, and there’s gaffer’s tape over behind there, and, ah, they’re not actually telling you the exact truth here, and it gets so…you don’t get an a-ha.
But there’s another side to magic: to make the trick look magical, the magician has to practice – the trick is a craft, and it can be finely honed. That’s why, before Teller does the Red Ball trick, Penn has to tell you how it’s done; you can’t appreciate the workmanship if you don’t know how much workmanship went in. The secret of the trick may be ugly, but the craftsmanship can be beautiful.****
Clouds, fog, atmospheric scattering – in X-Plane (and pretty much all rendering engines), these are not physics, they are magic, meaning they are tricks. The sky is a hemisphere around your head, like in The Truman Show. The color of the clouds are just painted onto textures with photoshop.
It’s trickery, but I feel no shame in these things, because the real physics are approximately a gajllion times more expensive than we can possibly afford on today’s hardware. A single square meter of ground (on an overcast day) might be lit by 10^18 photons per second – a lot more when the sun comes out, and each of those photons can take a different path through the atmosphere, bouncing off molecules multiple times before arriving at a surface. The actual optics of clouds and the atmosphere is incredibly complex.
The hard work and craft of the trickery is in making all of the tricks work together to make a unified effect, and this is where some of my time has been spent over the last few days. It is frustrating work because there isn’t a right answer (the way there might be in the programming of physics equations); instead it is a series of tricks and compromises that try to make an illusion as convincing as possible given limited resources.
Whenever I describe the code behind atmospheric scattering, clouds and fog to Chris, he is always horrified by the complexity, by the layers of tricks. But such complexity matches Teller’s the definition of a functional magic trick:
Make the secret a lot more troublethan the trick seems worth. You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.
If clouds and scattering weren’t so much trouble, they wouldn’t be magic.
* The field of real-time rendering includes computer programs that produce graphics at high framerates, like games and CAD programs. This contrasts it with the movie industry, where they can spend two years with a giant render farm to produce 90 minutes of final output.
** In 2004, we had the GeForce FX series and the Radeon 9700. The 9700 was insanely powerful for its time, but it only had a 24-bit internal floating point path, a 96 instruction shader limit, etc.; you could do per-pixel calculations but burning shader instructions to work in linear space wasn’t on anyone’s mind. The Geforce FX series was significantly less powerful. This chapter wasn’t published until 2007 – 3 years later.
*** The link is to a Radio Lab story about a man who tries to understand how his grandparents performed a mentalism act on the radio – it’s a good listen!
**** In Fool Us, many times Penn and Teller knows exactly how the trick was done, but still praise the magician for their presentation – because they know how the trick was done, they know how hard it is to do it well. Within the show, they seem to have a preference for tricks that are not easy and require skill to perform.
Robin, Tyler and I have been going through the airports that have been sent in since X-Plane 10.25; the good news is that there are over 350 batches sent in!*
But – I had to throw thirteen of them overboard; they were using OpenSceneryX. For airports that are going to be sent to the gateway and become part of the default airport file for X-Plane, you can’t use third party libraries! Everything you use has to ship with X-Plane.
WED 1.3 has user interface features to help hide third party libraries, but in this case you’d think that having the objects in the opensceneryx/ folder would have been a hint.
It’s not a coincidence that this was the same thirteen entries not sent in the right format; WED 1.2.1 won’t do an export for the global database with third party libraries, and this will be true with WED 1.3 as well, where the export is uploaded directly to the gateway.
My previous post described the dangers of relying on art controls for an add-on that needs to be forward compatible with future versions of X-Plane; the short version is that art controls are an internal tool and not a public SDK, so we don’t try to maintain compatibility with updates.
So I figured I’d blog about the other dangerous way to build an add-on: creating an add-on by modifying X-Plane’s files.
All of the well-supported forward compatible ways to make add-ons (scenery packs, aircraft, and plugins) work by adding new files to X-Plane, usually in a folder specific to your add-on (a scenery pack, an aircraft folder, or a fat plugin). This is very intentional – it ensures that add-ons don’t clash with our installer/updater over ownership of specific files.
But if you make an add-on that requires the user to replace one of our files with your own, all bets are off, and future patches of X-Plane will probably both screw up your add-on and be an updater nightmare for your users. The best bet is to avoid modding our files.
Use the Library
The library system lets you virtually replace our files without actually touching them by mapping your own art assets to a given library path. This is the right way to customize the scenery; editing the files on disk is not a good choice. We may move files around within our own art assets in an update, but the library paths remain the same. Thus building a library replacement is relatively safe; hacking the library scenery packs inside “Resources/default scenery” is not.
You should also use the library when you want to use our art assets; do not copy our art assets out of X-Plane into your scenery pack. If you use the library, improvements to the art assets are automatically transferred to your scenery pack.
Some Dangerous Files
Here are some files that really aren’t meant to be modified in an add-on:
Our shaders
Random bitmaps in Resources/bitmaps, including sky and cloud textures
Lights.txt (the configuration file for named lights)
These files are all really part of X-Plane’s implementation and change regularly as we try to improve the sim.
You Can’t Share Naked Textures
You might notice that there is no way to directly use X-Plane’s textures in your add-on. At best you can use the .ter or .pol file that references them.
This is intentional! Our artists may need to remap the location of elements within a texture as part of a future sim change, and when this happens, add-ons reference the texture would show the wrong part of the image. That’s why add-ons can only reference some asset that itself references the texture; if we change the texture, we change our .pol files or .ter files or what-have-you to compensate for the UV map change.
X-Plane Is Not a Library
Austin and I get a steady stream of “can we just get access to X for our add-on” where X is some part of the sim that the add-on maker would like to re-use. Unfortunately most cases where internals aren’t public are because we can’t safely share them; X-Plane is an application first and a library or platform second, and in many of these cases, to share these internal parts of X-Plane would be to commit to not ever making them better, which we don’t want to do.
I received an email yesterday that I found a little bit concerning; an author wrote this:
I hope 10.30 is not going to change any of the datarefs we as a community have identified and are using to make the sim better and if it does I will work to modify the scripts to make them work again.
Here’s the problem: his add-on is one of the new Lua scripts that changes the internal art controls for atmospheric scattering – it is almost certainly not built on public x-Plane SDK datarefs, it is built upon finding, locating, and hacking the internal art controls in the sim.
So I hope the author isn’t going to mind working to modify his scripts again, because those art controls will change.
Simply put, building an add-on based on art controls is like building a house next to an active volcano – it might be a nice place to live, but you’re going to have to rebuild your house from time to time. Be prepared to do your work over, because art controls will change – it’s a matter of when, not if. The rest of this post is some warnings, scare tactics, and an explanation of why the art controls change.
Scary Warnings, Etc.
In my pastcomments, both public and private, I have tried to be clear that the art controls are not a stable interface, they are subject to change, and that you can’t build an add-on that will keep working while we patch if you use them. (I’d also hope that the fact that every art control starts with sim/private would get people’s attention.) But I apparently never wrote one big public global “no warranty” message*, so…um…here we go.
The art controls are not a public interface to make X-Plane add-ons. They are an internal development tool. They are unsupported, undocumented, unsafe, and most importantly subject to change with every patch of X-Plane. If you create an add-on that requires reading or writing the art controls, you can expect that your add-on will stop working when X-Plane is updated. When your add-on breaks, please do not complain or file a bug.
So hopefully that makes things clear. Art controls will change,you’ll have to do your work over, and we’re telling (and have been telling) you that since people first figured out how to access them. If you learned about art controls from someone other than me and weren’t aware of this, the person who taught you forgot to tell you the most important thing.
What Is An Art Control
An art control is an internal hook into our engine that we use to tune and calibrate algorithms, measure performance, and debug problems. I started adding art controls so that:
Our art team could “tune” X-Plane without having to have the source code or recompile the sim and
So I could see the results of changes to the engine without having to quit and restart X-Plane.
They are a critical part of X-Plane development.
They are not, however, some kind of public interface for third party development. We have public datarefs, listed on the X-Plane SDK website, that let you replace the flight model, customize the control surfaces, etc. Those datarefs are a real “interface” to the sim – even when we modify X-Plane, we try to keep that interface working. Many of the public datarefs are over ten years old now.
By comparison, the art controls aren’t an interface – they are deeply tied to the how of the engine, e.g. the specific algorithm we are using today. If we come up with a better algorithm, those tuning controls lose relevance and the art control goes away.
Why Don’t You Make the Art Controls Public
The immediate question that most developers have when they hear my rantexplanation of art controls is: why don’t you make the art controls public so we can use them?
It’s a good question, particularly when the art controls are useful. The answer is that the art controls don’t represent a specification for what the sim does, they represent side-effects of the algorithm we are currently using. Let me use atmospheric scattering as an example.
Atmospheric scattering is essentially a mathematical formula (run on the GPU) that makes the color of pixels “more blue” when they are farther away. The art controls for scattering become constants in that formula – thus you can change the constants (but not the overall shape) of the formula via art controls.
But here’s the problem: the formula I use isn’t very good.** The result is that when the constants are high (for “heavy” scattering) the far view turns a really rich, electric blue that just doesn’t look anything like the planet we actually live on.
As long as we keep this formula, we’re stuck with two options, neither of which are much fun:
Keep scattering turned way down. This is what we ship with; clearly users want more scattering – you can see that by all of the positive reactions to add-ons that crank the art controls up.
Turn up the scattering and try to ignore the blue. This is what most of the scripts that hack the scattering art controls do, and I would say it’s clearly a trade-off.
So I am working now on a better formula, one that won’t produce incorrect colors at high scattering levels. But when that formula is done, it will be a different formula, with different constants in different places in the equations.
And that is why art controls change. The very code that gave birth to them changes, and they get deleted and replaced with new art controls. The only way to keep the scattering controls forever is to never fix the flaws in the current formulas.
What Art Controls Will Change, and When
First, I hope that if I’ve made one thing clear, it’s this: if you want your add-on to keep working with future X-Plane patches, you need to avoid the art controls.
Realistically, the art controls tend to change when there is major development in the sub-system that they are part of. So the shadow art controls will change any time we try to make the shadows better; the scattering art controls will change any time we try to make scattering better.
So if you are just tinkering with X-Plane, the good news is: if your art controls have changed, there’s a chance that you may be able to achieve a better effect using the new code.
One final note: if you want to build an add-on that needs to work past version updates (e.g. a payware add-on where having to follow our patch schedule is not a good idea) and the only way you can accomplish your goals is with art controls, send me an email. We may be able to add a real interface to replace art control hacking. This won’t always be possible, but sometimes it is, and the results will be a lot less work for your add-on in the long term and happier customers.
* See Resources/settings.txt for the warranty on hacking settings.txt.
** In my defense, the real look of the sky comes from a huge number of photons crashing into a huge number of molecules a huge number of times – we’re not even remotely close to having enough computing power to solve that honestly, so all scattering code is based on gross simplifications of gross simplifications.
A few weeks ago AMD posted a beta driver for newer Radeon HD cards that fixed some drawing artifacts with X-Plane. They have now released an official, non-beta WHQL that works with X-Plane. So if you have a newer AMD card on Windows, I suggest updating to the new Catalyst 14-4 driver.
(Spoiler alert: the answer to the “when” question is going to be deeply unsatisfying and annoy you. Sorry – there isn’t a date. But at least you’ll know what’s going on.)
It’s been over four weeks since Philipp publicly demonstrated an early X-Plane 10.30 build with the new GPS. What’s going on now? What about 10.30?
What’s In X-Plane 10.30
Here’s a rough overview of what’s going into 10.30. We’ll have a complete change log when we release a public beta; right now the change log is not compiled, and it’s going to be long enough that I can’t go through everything now for a blog post. (To give you an idea, Austin has 158 commits on his branch going in.)
The one truly big new features is the new GPS Navigator that will ship in X-Plane 10.30. Please note that an aircraft must be modified to take advantage of it. It looks like a basic modification (e.g. if the aircraft already has the old G430) should be a few clicks in Plane-Maker. Similarly, you can add the GPS to your aircraft with drag-and-drop in the panel editor.
Philipp has Oculus Rift support working but we’re still trying to figure out whether to ship it in 10.30 or wait; the actual Rift support is usable but the user interface is still quirky. Since they’re not actually selling devices to consumers yet we may wait.
We’re working on a number of visual improvements:
Tuning and improvements to the look of the clouds, including their behavior as you fly into and out of them.
Optionally increasing the distance the DSF scenery is drawn for better long-range rendering.
Better fog in lower visibility situations. (I’ll try to post some experimental pictures over the next few days.)
This stuff is not finished – in particular, my fog work is not done yet, but if we can get it all working together it should make the visual experience in X-Plane 10 a lot better, and a lot closer to what we imagined.
Under the hood 10.30 contains major changes to Plane-Maker’s panel editor and the entire OpenGL stack; these changes don’t provide any immediate features – this is just us putting in new infrastructure for future updates. I mention this only for completeness; infrastructure changes can cause bugs that we’ll fix before and during beta, but they’re necessary to keep the product evolving. The OpenGL changes in particular can affect plugins if they haven’t followed plugin SDK guidelines.
10.30 has some small extensions for third party developers, including a number of new dataref-based interfaces to customize sim behavior; we held off on this kind of thing during 10.20 to ship 64-bits faster so now we’re catching up on adding flexibility for third parties. I’ll post a complete list with the release notes; some of this work is already done and some is still in-progress.
Finally there’s just a huge number of bug fixes, including a number of high profile and stubborn bugs. Please do not ask about your favorite bug in the comments (I will nuke your comment!). We will post complete release notes when we reach public beta.
The Release Process
We’re trying two changes to our release process for X-Plane 10.30:
We are doing extensive private pre-beta testing before the public beta. Normally we release a public beta and get 300 reports that all tell us the same one big bug. This time we are starting with a much smaller group of testers and slowly growing it; this gives us much more efficient feedback and should speed the whole process up.
We are doing private testing on parts of the sim individually before we jam them all together. I’ve had users test my “lots of DSFs” code separately from Philipp having people test the GPS. Traditionally we’d test everything at once, and the chaos of having so much new code in one single build made life hard for both testers and developers. So this time we’re starting small and slowly bringing the pieces together.
(Please do not email or post requesting private beta access – we are not looking for additional testers at this time.)
This process is an experiment; when 10.30 is done we’ll have to step back and see if the added complexity saved us real development time.
When Will 10.30 Be Released
We are currently privately testing some parts of 10.30. My expectation is that we will reach a public beta of 10.30 with the GPS, but without all fog-related features in weeks. (I don’t know how many weeks – it depends on how fast the current bugs get fixed and what new bugs are found.) Austin and I have differing views on this; I always push toward “don’t public beta until all of the bugs are gone” and Austin pushes toward “let’s get people the new GPS ASAP.” I think the actual public beta will be somewhere in the middle.
The current plan is to get the GPS public before we integrate some of the newer fog features so that users can use the GPS (and third parties can start to add it to their airplanes) without everyone being held back on my incomplete fog code. We’ll roll the fog code in when it becomes stable enough.
What Else Is Going On That’s Not In 10.30
A few things that are not part of 10.30:
Alex is still working on autogen; we’ll release art assets when they are complete and shippable, but 10.30 won’t wait for them. (10.30 does have the autogen engine enhancements he needs.)
I still have a bug left to fix for DSF recuts; those also aren’t tied directly to 10.30.
The Airport Gateway and WED 1.3 (to send airports to the gateway) are in late development and early test; they’ll ship as soon as they are ready, but don’t require an X-Plane update.
Once the Airport Gateway is live, we’ll gather up all of the airports users have shared with us since X-Plane 10.25. We’ll include those airports in an X-Plane patch whenever they’re ready – if that’s after 10.30 we can do a small update to push out airports very easily.
Put another way, X-Plane 10.30 is mainly about code changes; if the various art asset and data updates become available early enough, they’ll go into 10.30 but if they don’t, we’ll do a 10.35 or some other small patch to get them to you as soon as we can.
OK you folks have not heard from me in forever, but trust me when I say it is because I am busier coding than you can imagine!
We are getting very close to X-Plane 10.30 Beta 1, and the feature-list is simply extraordinarily huge.
These will all be “making it work just perfectly” type features to really dial X-Plane in to the point that it is doing the job it needs to do, free of bugs or other quirkiness that make complex programs difficult to use. I will be announcing the beta when it is ready for public testing (we have been in private beta for some weeks now).
Next: Here is a cool new helo that was just introduced for X-Plane:
I usually do not announce each new craft for X-Plane since there are so many of them, but in this case I just had to make an exception since this bird looks just so darn good.
So, look for the public 10.30 Beta soon, and give the Dreamfoil 407 a try if you like!
austin
I’ve been meaning to post something about 10.30 too, but every day is exactly the same: I wake up, think I should post a status update and go “oh, I’ll do that later when I’m too tired to code.” Follow that with: code all day, survive dinner and bed-time with a two-year-old, and inevitably I end up being too tired to even post a status update.
I’ll get a few details up in the next 24 hours. Having put it in writing, now I can’t put it off anymore.
X-Plane has been lacking a decent navigation solution for general aviation aircraft for a long time. The built-in GNS430 instrument could only do direct-to navigation and not use X-Plane’s FMS plans, making long IFR flights inconvenient.
In X-Plane 10.30 we are introducing a new generation of the X-Plane 430 GPS navigator, modeled more closely after the Garmin 430W that is very popular in general aviation aircraft. The 430W is a popular aftermarket GPS replacement in many older general aviation aircraft, because it is approved for WAAS approaches and thus an easy upgrade to allow flying instrument approaches at lots of smaller airports without ILS.
The new X-Plane unit can create and fly multi-leg flightplans in addition to the direct-to function:
You can create directs or flight plans using a worldwide database of airports, fixes and navaids:
Loading or saving the route works using the X-Plane FMS format. Many online services for virtual flight planning are compatible with that:
You can then navigate along your flight plan using one of different map views that provide situational awareness:
While flying under VFR, stay alert to any Bravo, Charlie, Delta or special use airspace in the United states (open database, user-expandable):
You will be warned when you are about to violate an airspace:
using the nearest airport function you always know your nearest alternatives for landing (though we all know X-Avion does a much better job at that!)
With a little help from your friend, knowing when to start your descend becomes easy:
Before landing, always know who to call:
For IFR approaches, load precision and non-precision approaches from a world-wide, updatable database:
Review approach transitions and initial approach fixes:
and then load any approach and transition into your flight plan:
Under ATC (read: when flying online) the vector-to-final function will often be used instead of a transition:
The X-Plane 430 is there to help you stay alert to common errors in approach navigation:
The GPS is capable of flying non-precision GPS-approaches with a localizer-like guidance and varying CDI sensitivity:
If you don’t see the runway at the minimum descend altitude, continue to the missed approach point and the flight plan sequencing will go into suspend. At the missed approach point, if you still don’t see the runway, begin your missed approach:
and then get help choosing the right entry to the missed approach holding:
The new GNS430 is a drop-in replacement for the old one, so every X-Plane aircraft equipped with the GNS430 automagically becomes more IFR-capable with the 10.30 update. We also provide an additional instrument in style of the bigger GNS530, that designers can use in their aircraft starting with Plane-Maker 10.30. It also allows for dual installations that can either use separate flight plans or cross-fill.
The interaction of the GPS with the rest of the panel, especially the CDI and the autopilot, has been improved, offering a few more options for aircraft designers. Two additional posts explaining the new options in Plane-Maker will follow shortly.
The database from which approaches are loaded is provided by Aerosoft. A current database will be provided once with X-Plane 10.30, and further updates will be available on a subscription basis.
You might have noticed stupid COM frequencies in some screenshots. This is not a bug, but a feature: X-Plane 10.30 supports 8.33kHz channel spacing, that is now mandatory in the European upper airspace and will become more important over the next few years.
For the inevitable question “will it have X and does it simulate Y?” I do have one answer:
I chose the feature-set for the 10.30 release carefully to fulfill two requirements:
It must simulate the functions I use every day. After spending about 40 hours flying a C172P with this equipment, I have developed some pattern in day-to-day use. The simulated equipment must have the functions I use every day.
It must simulate what I need for my IFR checkride preparation. I’m currently studying for the instrument rating. All IFR GPS functions that are needed during the lessons must be simulated so I can use X-Plane to practice at home.
This does not cover all functions of the real unit, but it covers what the pilot absolutely needs every day.
I have been working on visibility and fog-related bugs in X-Plane 10.30; two fixes will improve high-altitude long-visibility viewing:
10.25 has a bug where the fog color changes abruptly at the cut between DSF and planet rendering, particularly when atmospheric scattering is on. This is fixed in 10.30
The 64-bit version of X-Plane 10.30 will load 12 DSFs instead of 6, for longer-range drawing of detailed DSF terrain.
These comparison shots show 35k above KSEA looking at Mount Rainier with max visibility. (Note that at 35k feet, it doesn’t make a huge difference what ground visibility you pick – the planet-wide upper atmosphere model is almost entirely in control.)
X-Plane 10.25 32/64-bit
X-Plane 10.30 32-bit
X-Plane 10.30 64-bit
These pictures are taken at “very high res” – the most my Mac Pro can survive with an old GPU; you might get a little bit better definition on “extreme” res.
More DSFs
A few notes on loading more DSFs:
My current plan is that the 64-bit version will always load the 4×3 DSF box – if we have to make this a setting for compatibility we will, but I think it’s preferable to not add more rendering settings.
The 32-bit build will stay with a lower DSF count for memory reasons; generally speaking, I don’t think we will have any additional visibility improvements in the 32-bit build since we are almost always going to hit a memory wall. If you have a 32-bit OS, consider upgrading to 64-bits! (In particular, if you are running Windows XP, please upgrade to Windows 7 or 8 64-bit – there are no more service packs for Windows XP, so you’re just asking to get malware!)
In 10.30 the DSF loader can load up to 4 DSfs at a time (for 4×3) or 2 at a time (for 3×2). So if you have a multi-core machine, the load time should be better even though there are more DSFs being loaded, thanks to multi-core. (The limiting factor here is that adjacent DSFs can’t be loaded at the same time because their edges need to be matched.)
I am still hoping to address other low-visibility fog issues, but that code is not complete yet.
The Planet Could Look Better
X-Plane renders nearby terrain using DSFs, but it renders the very far terrain and entire planet using a single “planet” model, which is a textured sphere displaced by a normal/height map. As of X-Plane 10.25 (and 10.30) we are not including as much detail in the 3-d planet mesh as the data on disk contains.
This pair of pictures is 45k above LOWI; the second texture has the mesh spacing on the planet artificially increased from 3 km to 2 km. (The data on disk is at 1 km spacing, but my machine can’t cope with that.)
10.25, 10.30
Extended Planet Detail – Maybe for 10.40
You can see we pick up a little bit of definition in the far mountains. In the long term, I think we could ship a 500 meter planet mesh, which would make the far view in X-Plane as good as the close view used to be in X-Plane 7.
I’m not sure when we’ll ship a higher density far-planet, but I think it will have to be post-10.30.
If 1 km or 500m seems like bad resolution, do consider how far away the planet mesh is. With a 4×3 DSF box, the planet starts 100 km from the viewer. At 90 degrees FOV (an extreme case, but it makes the math easier) the screen is 200 km across at the DSF cut-over. With a 2 km planet grid, that means we will show 100 planet vertices left-to-right. At 1080p the planet triangles are thus at 20 pixel increments – not bad for a low res mesh.
