At the X-Plane Developer Conference in Montreal this year I gave a presentation sharing my thinking on our next-gen scenery system. This has created a lot of interest but also a lot of confusion. So in these next two blog posts I want to start by clarifying two fundamental ideas about scenery.
Here’s the key point for the first one:
A new scenery format is not the same as new scenery.
This can be confusing because we haven’t changed either our scenery file formats or our scenery in quite a while, and often the two change together. Let’s break this down.
A scenery file format is the way we represent scenery in our simulator. It consists of several things:
- A file format specification, describing how scenery data must be encoded.
- A file parser inside X-Plane that can read those files.
- A renderer inside X-Plane that can render those files.
- Tools that help people encode those files.
My first work for Laminar Research (two decades ago) was building all of those things: I invented DSF files, wrote the DSF reader inside X-Plane (DSFLib), worked on the rendering engine, and created the tools to write the files (DSFTool).
When we talk about just the scenery, this is the final rendered files that people fly with. Remember when we shipped 60GB worth of content in 12.0.9? That was new scenery rendered out with all the latest and greatest data.
X-Plane ships with the “global scenery” – a set of about 18,000 DSFs that ensure land everywhere from 60S to 75N. But this is not the only scenery out there – there’s TrueEarth, HD base meshes, SimHeaven, and scenery made with Ortho4XP.
Lots of people can make scenery, often in many different ways (using land class, orthophotos, autogen, etc.) but all of that scenery must be in X-Plane’s scenery file format, e.g DSF.
The scenery is the turtle and the scenery file format is the shell. The scenery can only be as complex as there is capacity in that file format (shell).
So the first part of my talk was a tour of how we have outgrown DSF, and pointed out that there are some things that DSF can’t do. For example, several add-on makers want to stream custom scenery, but DSF makes that basically impossible. DSF also isn’t meant for really high detail vector data, so we’ve been having trouble using all of the latest OSM imports.
The second talk discussed our plans for a replacement to the base mesh file format, which is based on raster tiles. This part of the talk said nothing about what kind of scenery we (Laminar Research) would make, which raised a lot of questions.
But now that you understand the the turtle and the shell, you have a lens to understand what we’re saying. This wasn’t an announcement of next-scenery, only an announcement of a bigger shell that will make that next-gen scenery possible.
So the next-gen scenery format is all about potential. The scenery file format limits what is possible for all scenery (both what is built into the sim and add-ons), so we want to raise those limits quite a bit in the next-gen base-mesh format.
The way we are doing that is by moving the base mesh from a vector-centric approach to a raster-centric post; I’ll break that down in another post.
So with all this going on…. what is going to happen to the 8TB+ of Ortho4XP scenery files presently installed on my system. Will there be a way to convert to the new file format? Thanks for the great software. Cheers
I do not know if there will be a way to convert them, as Ortho4XP is a third party tool. They’ll keep working – we are NOT NUKING DSFs. But the new system will be much better suited to using their data directly.
Support for airport mesh editing? (fingers crossed)
It will be possible to patch the raster elevation layer in an overlay if it is on top of a next-gen base mesh.
Well I for one welcome the growth of our beloved turtles. But where are the scutes? What do we do with them?
Hey Mr. Ben! It’s great to hear from you again. I was wondering, I have seen several youtube videos about how to make scenery/landscapes in blender and it caught my attention in a way to make me question “can those blender made landscapes be possible for a next gen X-Plane global scenery? and if yes, then how?”
What are your thoughts about this? I’m sure the scenery engine would probably reach some limits there but hearing from you about this topic sounds more interesting.
The answer is “kinda”. Our current thinking is to use 3D tiles 2.0 (the Cesium spec thing) on top of base mesh raster tiles, and this would allow for “modeled” detailed terrain. This would mean it would be possible to make scenery with Blender, but I would _not_ recommend it and I don’t see it as being the way for X-Plane.
Thank you Ben for highlighting this. A dream scenerio for me would be something in order of https://outerra.com/, which I think has the best looking scenery foundation out there. Now the concept is quite differnt I know, but the idea is similar and I guess shows what is possible with C or C+ programming. If I were to imagine, this is something that would mean building X-Plane up from scratch again, which I think is an overwelming idea. However perhaps there are bits and pieces or even new techniques to learn from it? Anyway just a small intro on top of the subject. What I really was asking about is this. You mentioned a few things in the Q&A about KTX containers, I did not read anything about this. Suffice to say is this something you plan further to be part of any new scenery? Or perhaps is targeted for your next post, if not can you talk about it?
I am aware of Outerra, and it is technically impressive, but it is not solving the problems we are trying to solve.
I think I save this topic for an later Q&A as to what vision you guys see X-Plane scenery in the future as to how it can look better than today 🙂 Thanks for respondering Ben, response is understood.
When do we speak about the Turtle itself than?
Ben, thanks for outlining these intentions.
Can you, in the context of Turtle and Shell, explain the dsf format in terms of all the newly introduced “layers”?
Old scenery which includes dsf files created during XP11’s reign, and the expanded dsf layering operating in XP12?
Thanks for restrting this regular blog series.
DSF is the “old” shell – the container for both base meshes and 3-d clutter now. We are building _new_ file formats for next-gen work, while supporting DSF for backward compatibility. We are not extending DSF.
I am glad that you also perceive these problems. As a 3rd party scenery developer, I feel that the scenery in X-Plane is one of the weakest parts at the moment. The animation, for example. The animations are interestingly handled in X-Plane, based on datarefs and it’s great when you need to base the animation on some external influence, like weather, wind, or user influence e.g. button presses or lever pulls. However, it doesn’t allow you to import advanced organic animations – like people walking or rubber deforming on a jetway. I believe allowing this to developers would bring a lot of new content to X-Plane. Yes, there is a way to import this even now, however, this option requires “rendering” each frame and so the complete model may repeat based on the number of frames, so a newer way of importing animation would be welcome. Another thing the developers would appreciate is better terrain modification. Whether to be able to color the terrain or modify its height, flatten it, or add ponds of water. These are the two things I see as the most pressing issues at the moment. Of course, we can talk about how to render models and how we can use more textures to get a better result, but here I think X-Plane already achieves very good values. The only thing I would focus on in the rendering side are the reflections, they are very unrealistic.
The only thing please don’t redo is how the scenery itself is built. The World Editor is a great tool and I definitely wouldn’t change it. If you want to move development straight to X-Plane, I would be careful and offer developers the option to combine it with World Editor.
Thank you for the lovely service, you provide for us, Ben!
I would expect WorldEditor to keep on working and adapt, but MeshTool to be retired.
Organic animations aren’t a scenery issue, they’re a _modeling_ issue – the aircraft people are just as (or more) annoyed by the current animation tech in OBJ. We’re working on moving modeling to glTF 2.0 with skeletal animation, but this is a long term goal.
Glad to hear that! Thanks a lot! Looking forward for future updates!
I loved the Orbx True Earth scenery for the UK that I used in X-Plane 11. It was very accurate for practicing VFR flights (paired with SkyDemon for navigation) before I made them in real life in a good old Cessna 172. That’s the sort of level I’d be hoping for from scenery, as a real-world use case.
This is very interesting, Ben. Is this new reptile going to be part of X-Plane 12, or are we just talking about The Glorious Future?
Hey, Ben,
As you wrote in your comment, Meshtool is retiring. So will there be a similar tool publicly available soon or will we have to rely on third party tools like Ortho4XP, etc.
New tool from us to convert GIS data to raster tiles. Because the raster tiles are way more flexible in how they consume data (and in requiring LESS data), the new tool should be _fundamentally_ less annoying than MeshTool…most of MeshTool’s annoyance factor comes from “you need 8 tons of crap to bake the DSF”, which is a DSF thing, not a mesh tool thing.
Okay, thanks for the answer.
One more question, will it be able to create Mesh only and the rest will be through worldeditor, or will it be possible to export ortho, forest etc. using shapefile data.
It’s too soon to say how WED and tools for the new system will interact.
Hey Ben, when will there be an implementation of an internal FOV and external FOV? For instance if I want my aspect ratio to be 75 inside the aircraft and then my aspect ratio to be 45 external out of the aircraft.. when will this be implemented or is there any plans for that?
Thanks,
Ben
No plans for this. This can be done by plugins now.
Thanks for this update.
For AutoOrtho and whatever comes after it we would love a callback in the plugin API when a texture is accessed that would allow us to return data or a file descriptor. That would simplify and probably speed up things a lot and allow us to get rid of the dynamic file system and more easily support Windows and Mac. For asynchronous downloading we could even get a method to tell X-Plane that it should reload a certain texture? The latter would allow us to prevent stutters completely.
I feel this has more interesting use cases for scenery designers as well.