Before I can describe the way we are planning on handling Jetways in X-Plane 10, I’ll have to describe some of the rendering technology that goes into the lego bricks; the airports are built on a bunch of new version 10 features.
- Global lighting. The airport objects come with lights that cast halos in all of the expected places. Sometimes the light is attached to a building, but there are also tand-alone “light pole” lights. This simplifies placement and arrangement because you don’t need to worry about matching LIT textures on the ground to your objects. You simply place lights and the resulting lights do what they should. If things are too dark, just place more lights.
- Draped geometry in OBJs. In version 10, an OBJ can have draped geometry that sits on sloped ground perfectly. Tom uses this for parking spot markings, etc. To place a parking spot, it’s one click in WED to place the object and you’re done.
- Improved OBJ performance. On machines with new video cards, we use instancing to draw OBJs if they are simple enough (e.g. no animation, no material attributes). This means that the cost of very small, simple objects is much lower than in version 9. Thus you can place a lot of clutter on the apron and it shouldn’t hurt performance too much.
- Attached objects on facades. A .fac facade definition in version 10 can have attached objects, the same way the roads do in version 9. In version 9 we used attached objects to add pillars to road bridges; in version 10 Tom can attach a light pole object to a facade and it will automatically be placed in alignment with the facade section that it matches.
- Custom facade wall selection. in X-Plane 10, you can pick which art asset wall definitions are associated with a given facade. For example, when you place the fence facade in WED, you can pick which section has the gate. When you place a terminal, you can pick which sections have windows and which do not. (The wall selection is made via a popup in WED – WED reads the wall names out of the .fac file.)
- Autogen Point scenes (.agp files). An autogen point scene is a draped footprint texture which is annotated with a mix of vegetation (defined by a .for file), objects, and even facades. Tom builds the .agp in Blender, forming a “mini-scene”. You place an .agp just like an OBJ in WED – you specify its location and heading – point and click. (The file is called autogen point because it is located at a single point in the DSF.)
- The ground tile from an AGP can use a special shader that adds various amounts of grit and other high-res textures; a control texture with primary colors painted into it specifies where the various high-res texture effects take effect.
Autogen point scenes allow Tom to build a building that comes with extra objects (parked cars in the parking lot, a mailbox), facades (a fence around the object) and a draped polygon all in one click. Putting it all together, you can place an autogen scene in one click and get a facade with exact wall types, lots of objects (that run quickly) with instancing, and global lighting shining on the entire situation.
All of this rendering tech is also completely available to third parties – you can make your own .agp art assets or your own facade types with custom walls, etc. Everything that the airport lego brick library uses will be available via text files in your custom scenery pack.
There were a bunch of questions in the comments about the airport lego brick system. We’ve talked about it a bit, but we’ve never really described the project in one place. Tom sent out some pictures of the system as he was testing it, so I’ll repost them and explain what’s going on.
First, the basic idea: for the last few versions, X-Plane 9 has shipped with default airport layouts (built off of the apt.dat file) but no buildings. The apt.dat file is an open source data file managed by Robin Peel; Robin integrates multiple public data sources and users submit their own improvements and changes. The result is high quality airport layouts despite the lack of a good free global data source.
When we were first looking at new features we wanted to put into X-Plane 10, airport buildings were a high priority; we didn’t want the airports to be empty. Thus airport lego bricks were born. The idea is:
- Our art team builds a series of useful art components for airports (“lego bricks”), e.g. terminal buildings, hangers, light fixtures, trucks, etc.
- LR seeds part of the world with some initial buildings. I don’t yet know how many buildings we will put down. When an airport layout is automatically generated by Robin (just a runway and taxiway) we can easily put down buildings, but for a more complex layout a human may have to look at the layout and say “that’s where the hangers go.”
- WorldEditor 1.2 will have features to edit these layouts. (Tom is using WED 1.2 now – in fact, the source is posted. It’s my hope that we can get WED 1.1 out ASAP once X-Plane 10 is available.)
- LR or Robin or someone collects the placement data for these structures and integrates user submissions, as well as layouts that LR builds internally.
- The new data from all sources goes into X-Plane updates so that users get new layouts quickly.
The lego bricks come in forms you already know of: OBJs and facades, as well as a new “autogen point” file which I will explain in another post. Here is a picture of WED 1.1 with a simple airport layout that Tom built.
The green polygons are forests; the gray polygons are facades. In X-Plane 10 and WED 1.2 you can pick the wall types for each wall of a facade, so the walls are now color coded. (When you select the facade, a popup menu has names like “wall with jetway” or “glass wall”.) Placements of OBJs and autogen have real previews from the top down.
It is my hope that building these kinds of scenes will be easier than building the underlying pavement, because most of the airport elements are drag & drop objects, e.g. you just point and click; the facades are simply traced as outlines. To build a layout using these parts you won’t need to know how to use a 3-d editor, hack an OBJ file, texture-map a 3-d mesh, and you don’t have to do your own texturing work.
But what do the results look like?
ff
Not bad for point and click. The airport lego bricks leverage the rendering engine enhancements in version 10 to provide a lot of detail without having to build a custom scenery pack:
- Since X-Plane 10 has global illumination, light fixtures (either attached to a premade object or in one of the dedicated light posts) simply shine down on whatever is nearby. Put an airplane under a light post and the results look correct – no render-baking required.
- The version 10 facade engine is greatly enhanced; that terminal with jetways sticking out is a v10 facade, and it is in full 3-d.
- X-Plane 10 features new shaders that add extra detail to surfaces – that’s where the grit is coming from in the driveway in the third picture.*
- If the user enables shadows, 3-d casts shadows on everything else. Put a car next to a building, and it will be in shadow, but only at certain times of day.
We have not yet built the submission editing and review process, but at this point the plan is to collect and redistribute overlay DSFs – they are the logical container choice for a bunch of OBJ placements. We are not planning a special .dat format for these buildings.
A few other questions that have come up:
How will ATC data be handled?
Traffic flow information (e.g. where the planes taxi) sits inside the apt.dat file and will be collected as part of the regular apt.dat process. Non-airport ATC data will be collected separately; more on that some other time.
Can this be used for custom cities?
No. The scope is strictly airports. We can collect placements for airports because:
- Airports start out truly empty – the DSF generator clears them out. So there are no conflicts with autogen. For cities, we’d have to “coordinate” with the default buildings and roads, which gets complicated fast.
- The number of “things” in an airport is small – maybe hundreds if you really get into detail, compared to hundreds of thousands for a city. So it is practical to completely build an airport.
- Because one person can build an airport, we only have to worry about conflicts between submissions – we don’t have to worry about merging several parts of a city.
- The set of art assets we need for an airport is limited, so we can provide a reasonably complete library.
- Airports are really important to a flight simulator, so it’s worth all of the effort on everyone’s part to do this.
Generally speaking, I would like to increase user involvement in all parts of the scenery process. I get a lot of emails where people ask “how can I change X” or “can I fix this and send it to you”. The scenery system needs to address both highly skilled authors making complex custom payware packages and casual authors who want to do a freeware pack or just contribute to the overall quality of scenery. So we’ll be looking more at how we handle cities and OSM data in the future. For now we have our hands full just getting OSM water and roads into the sim.
Can we use other objects, custom or from OpenSceneryX?
No. The default layouts need to be built entirely from art assets that ship with the sim. We think OpenSceneryX is great, but the goal of the airport lego bricks is to solve a small, specific problem in a self-contained way, so that people can download the sim and immediately see buildings.
How does this relate to custom scenery?
The lego bricks definitely do not make custom scenery unnecessary – they provide a general set of elements for airports, but I think users will continue to want partially or fully customized airports.
A good analogy is the default instruments: because X-Plane ships with over 900 premade instruments, a user can rapidly build a decent looking 2-d panel with no photoshop or dataref work. But to make a panel that truly looks like the real plane (or to work in 3-d) custom work is needed – it’s more effort but the results are better. Airports will be similar: generic layouts will look good, but custom work will look better.
(Could a payware custom scenery pack include generic elements? I don’t know. In the airplane world, if a payware airplane contains default instruments it tends to get poor reviews. But I don’t see why a custom airport couldn’t use our lego bricks for some of the smaller elements like light poles and baggage trucks, if the main buildings were fully customized.)
* It is possible to make grit effects in X-Plane 9 in the same manner that it is done in MSFS: place a translucent overlay polygon with a high-frequency repeating texture on top of the surface you want to make “dirty. Having this capability in a shader in X-Plane 10 improves performance – we can draw one layer of “stuff” and have all of the effects go down at once.
If you want to submit an airport layout to Robin in time for the X-Plane 10.0 scenery render, please submit it to him by October 1st, 2011. See http://data.x-plane.com/ for more info on the apt.dat file.
(And yes…my previous estimate for when we’d be cutting the scenery was off by a lot. I apologize to everyone who crunched for that deadline. For what it’s worth, I told Austin that if we didn’t get X-Plane 10 out this year I’d cut off one of my fingers.)
We will not be accepting ground traffic flow layouts for the new ATC system or user-submitted building placements before the sim is released. Once the sim is out there we’ll start working on that process. Our intention is to collect and redistribute airport building layouts and ATC data (using X-plane 10’s new airport element art assets) the same way we do for apt.dat files.
WED 1.1 beta 4 is now posted – see the Scenery Tools wiki for download links. Thanks to Matthias for the patches to remember the hierarchy’s open/close state – I suspect a lot of users will appreciate this detailed touch. Thanks also to the handful of users who tested some early versions of this beta – there are a bunch of big changes in beta 4 that needed a few tries to get right. (If you find bugs in WED or any of the scenery tools, please report them here.)
This will hopefully be the last beta for WED 1.1, setting us up to move on to WED 1.2 with X-Plane 10 editing features; beta 4 contains three areas of improvement that had needed attention.
Correct Preview Order
WED used to preview scenery based on the order of your work in the hierarchy. This isn’t so good because X-Plane has its own draw order based on layer groups. The next beta will do a much better job of showing the final draw order that X-Plane will use, so you aren’t surprised when you view your exported scenery.
Saving Work When the Undo System Blows Up
There has been one data loss bug in WED that has persisted since version 1.0: if the undo system blows up, you get a nasty error (“WorldEditor has hit an error due to a bug. Please report the following to Ben…”) and no chance to save.
The next beta will automatically save your work in a special file (earth.crash.xml) that you can use to get your work back in the event that the undo system blows up.
Why does WED crash like this at all? The problem is that the undo system saves incremental deltas as you edit your project, to save memory (so we can have a gajillion levels of undo). If the book keeping gets screwed up, we are hopelessly borked because with missing deltas we can’t ever get the project back to a state that makes sense. Once we lose deltas, we’re lost. The error dialog box pops up when it does so that we can know that the problem is with the undo system – otherwise we’d just have an inexplicable crash with no idea what went wrong.
When last I checked, there were only one or two users still seeing undo problems – I’ve added additional logging, so if you do see problems please file bugs!
Changing the File Format
WED 1.0 uses a database as its file format. While this seemed like a good idea at the time, it has since proven to be a performance and maintenance problem. The next beta of WED will use an XML file format.
WED 1.1 will still read the old database format (including the format used in previous betas), so you can open your old projects. Projects saved in the new beta will not open in the older betas, but this is no surprise.
For the nerds: when I first started working on WED, I thought that it might be useful for WED files to be databases so that bulk operations could be performed on large quantities of data. Since then I’ve realized that WED isn’t a GIS or spatial database app – rather it’s a modeling tool. The new XML file format is basically a direct output of its internal editing-centric format.
My previous post announced that a previously pre-computed operation (setting up the elevation of a DSF) will move into X-Plane in version 10. We have multicore and we can save some space and improve quality.
This led one commenter to speculate as to whether the entire meshing process can move into X-Plane. Unfortunately it cannot; a lot of other scenery creation processes are tied to pre-building the mesh, and some of those are still very, very slow. But it does beg the question of how more we might move into X-Plane.
The Original Precomputation Decision
The original DSF strategy (designed for X-Plane 8.0 a long time ago) was to pre-compute all of the difficult problems for scenery tiles so that X-Plane could simply load the data and draw it. This got us four things:
- We could use expensive algorithms to build scenery without hurting sim performance.
- We could pre-optimize the scenery for fast frame-rate, even if those optimizations were slow to compute. (No one cares if building the scenery takes longer, that’s done before your DVD is burned.)
- In some cases, we could reduce data size if the finished computed output was smaller than the input files.
- Scenery is deterministic – because the work is done ahead of time, changes in the sim don’t affect how scenery looks. New scenery technology mostly goes into the off-line scenery generator, which means less backward compatibility work.
The down-side of this decision was that we didn’t have a good way to integrate or modify scenery data on the fly. Changes in apt.dat files, for example, are not reflected in the scenery, since the scenery is already “fully baked” when the sim boots.
From Precomputation to Multicore and GPU
With X-Plane 10 we’re doing a few things to move rendering work from “ahead of time” to “while you fly”, using multiple cores and the graphics card for the work, since those are areas where computers have gotten a lot more powerful.
- In X-Plane 9, terrain is selected by slope (among other things) – this is why you see steep cliffs and moderate scree above grass and forests on a mountain side. In X-Plane 10, some of this happens on the GPU – we build a single shader with three terrains, and the GPU picks amongst the terrain on the fly.
- In X-Plane 9, we pass the raster elevation mesh to the DSF loader, rather than bake it into the mesh. Eventually we may be able to pass this data directly to the GPU.
These two techniques are meant to someday play together: if the GPU has the elevation and knows how terrain changes with slope, then we can have detailed terrain on the GPU without bogging down the rest of X-Plane.
Going Further
How might we further push this technology? I can imagine that at some point, if the sim can arbitrarily increase the triangle density of a mesh using the GPU and the raw elevation data, then we could reduce the triangle density in the DSF to only the triangles needed to represent land class changes, saving DSF space.
Using a triangulation to represent polygonal vector data isn’t as crazy as it might sound; there are a number of computer algorithms that subdivide polygons into triangles to lower the computational cost of processing them. (We even use one such algorithm to simplify complex polygonal shapes – see MapHelpers.h in the scenery tools code for the scary details.)
So in the long term the triangle mesh that drives X-Plane scenery can change from an approximation of elevation (with terrain along for the ride) to an optimized way to store terrain polygons (with elevation to be applied later).
Here’s a clearing house of past links on the topic of precomputation and global scenery:
Two more pictures from the test package Tom sent me. These illustrate both some cool things that happen in X-Plane 10 with global lighting and the process of adopting the new features. Our strategy for the new rendering features in X-Plane 10 is 3-fold:
- When the new features (shadows and global lighting) are off, scenery that works in version 9 should just work. So users always have the option to turn off the new features, use existing scenery, and get some fps back.
- We try to minimize the artifacts between new features and old scenery.
- We try to minimize the amount of rework necessary to be fully compatible with new features. For example, switching from ATTR_poly_os to ATTR_draped is a simple search-and-replace job.
The hangar during the day, with shadows with visible skylights, required some bug fixing in the engine, and a new attribute. Normally an object is either blended or not blended. The problem is that a blended object doesn’t let light through for the purpose of shadows. (Even with the “bug”, the hangar with shadows still looked pretty good!)
X-Plane 10 introduces a new OBJ attribute, ATTR_shadow_blend, that will make an object translucent for rendering (note the grime and dust on the windows) but fully transparent for shadows (hence the skylights let light through). The attribute works the same as ATTR_no_blend syntax wise, making the update quick.
(You don’t have to use this attribute, but without it, the sim may not be able to produce quite as nice shadows. Note that this attribute is not necessary for objects marked “glass” on an airplane – they are already handled by a separate process.)
There’s a second bug, visible in both pictures, but more visible in this second picture; the static airplane, which is from version 9, contains a ‘fake’ shadow, consisting of a single quad on the ground via ATTR_poly_os. During the day, we have a double-shadow (both the one generated by the sim and the fake one) and at night the fake shadow does not go away.
With X-Plane 10, this kind of problem (a technique that is useful in X-Plane 9 clashes with new rendering settings) can be addressed via the conditional OBJ commands. The conditional commands let you specify that certain parts of the OBJ are only to be used if the user has shadowing off (or global lighting off), for example. Thus the old shadow works for users who turn off shadows, but goes away when the sim takes care of it. The same technique can be used to have two versions of LIT textures (or even remove LIT textures) when global lighting is turned on and off.
One user asked me about slow performance with an overlay scenery he created using GMaps. There are three things you need for fast orthophotos in X-Plane, and unfortunately his scenery is missing one.
Use DDS
I’ve written before about DDS. They key points here for orthophoto performance are:
- Since DDS is already compressed, the CPU has to do less work preparing the texture if it is going to be compressed.
- Since DDS is already pre-minified (meaning the smaller versions of the texture are already computed), if you are not running at ‘extreme’ resolution, the sim can simply load a lower res version. With png, X-Plane must load the full size version and scale it down on the CPU.
- Since DDS is already pre-minified, the sim doesn’t have to compute those minified versions of the texture on the CPU.
All of these things lead to much faster texture load times with DDS.
Use LOAD_CENTER
LOAD_CENTER is a directive that can be put in a .pol or .ter file to tell X-Plane at what location the texture needs to be at maximum resolution; X-Plane will reduce the resolution of the texture as you fly away from that point. LOAD_CENTER is important for orthophotos for a few reasons:
- It saves VRAM, since textures that are far away won’t be loaded at full resolution.
- When combined with DDS, it improves load time. Since some textures are loaded far away, they can be loaded at lower resolution, which (per above) is quick for a DDS file – less data, less load time.
Note that LOAD_CENTER causes X-Plane to reload the textures while you fly, so it requires at least one extra core to work well. It’s really important to use DDS with LOAD_CENTER; otherwise that reload time can get expensive.
Use a base mesh, not draped .pol overlays.
This is probably the most important thing: if you want to cover a lot of area with orthophotos, you need to rebuild the base mesh using .ter files, not cover it with .pol files. There are a few problems with using .pol files:
- Draped polygons are only ‘built’ for areas relatively near the airplane. So even under ideal circumstances, they are going to disappear in the far view. This way of using them (only when near the airplane) is a memory savings based on their intended use: for small surface areas like airports.
- Similarly, since the draped polygons are being built and destroyed as you fly, the amount of extra CPU work while flying is quite a bit higher with .pol files than with a base mesh (which only has to page the actual terrain). So a computer that might be fine paging .ter files can get behind in its work for .pol files. (Authors often use .pol files because they are easy to work with – specify a rectangle and X-Plane does the cutting and slicing…well, that work is happening while you fly, burning up CPU power that could be used to page the orthophotos.)
- Since .pol files cover the base mesh, you pay for your mesh twice – once when X-Plane draws the base mesh and once when it covers over it with polygons. This means twice the VRAM used to draw a frame and twice the fill rate.
If you want high performance orthophotos over an area any larger than an airport or down-town, please use .ter files!
These four buildings are facade-scrapers, a new feature in X-Plane 10.
X-Plane 8 and 9 support facades. A facade is a building definition that is extruded to an arbitrary shape and height specified in a DSF. Facades allow us to build custom-shaped buildings that fit a precise footprint. The walls are created by cutting and repeating a grid texture of windows.
With a facade-scraper, two objects are placed in the center of the facade to form a tower. The facade base itself can exactly fit a city block, while the OBJ pair gives us a tower with architectural detail.
This is a wire-frame view; the facade itself is wire frame, and the ground is wire-frame, revealing the two objects. The base of the facade sits on the ground, but the tower can move up and down, with excess underground. This allows us to customize the height of the building to precisely meet the DSF height.
(This facade is a test case that I built out of Alex’s Chrysler building; the UV mapping on the base is pretty rough since I was just creating test files.)
We have not been adding features into X-Plane specifically to aid conversion of scenery from MSFS (and I don’t think we will), but sometimes features we want outright help solve conversion issues too. Here are two new features I expect us to ship in version 10 that should help the conversion of overlay scenery packs.
Draped Geometry: I’ve mentioned this feature before; basically in X-Plane 10, the horizontal geometry that sits “on the ground” can be marked for real 3-d draping, rather than just polygon offset. Draping is the process of actually cutting and shaping that geometry to perfectly ‘hug’ the ground – it’s how we can put a runway or taxiway on top of non-flat ground without Z thrash.
In X-Plane 9 you can create draped geometry, but you have to use .pol files; this can be awkward if you want to put an element in many times, share an element with other authors, or have an element on the ground match a 3-d object.
In most of the cases where I have seen serious Z thrash in scenery conversions, simply changing ATTR_poly_os to the new proposed ATTR_draped will fix the problem.
OBJ Elevation Control: X-Plane 10 will allow you to position an object vertically as well as horizontally, probably with something like this RFC.
For scenery conversions, this means that a scenery pack authored to a specific height elevation can be duplicated precisely.
For authors creating new work, this makes certain kinds of scenery possible that would have been very difficult before. For example, we get asked fairly often about LPMA. which features a runway on pillars. You can model as this as an OBJ with a hard surface, but in X-Plane 9 it’s very hard to predict what height that OBJ will be placed at. (Hack/work-around: place the OBJ in the water and model the geometry offset from the runway location. Most scenery packs should have the water at MSL 0.) With elevation control, the runway can be built at the real runway surface height and will be placed their explicitly.
Alpilotx pointed me toward a thread on the org discussing Austin’s work on the weather system. The thread turned into a bit of a he-said-she-said with regards to Outerra and whether it could some day be combined with X-Plane.
This blog post will be a discussion of various general approaches to scenery and the trade-offs we have to consider, e.g. plausibility and realism, procedural vs. algorithmic and data driven design. But first, a brief note on Outerra. As I have said before, we are already aware of Outerra, so there is no need to email us. The bottom line is that we have a set of mostly done features for X-Plane 10, our goal is to finish X-Plane 10, and we are not even spending one brain cell considering putting a new rendering engine into X-Plane while we are trying to get 10.0 done.
Defining Some Terms
One of the problems with comparing scenery system approaches is that a real productized approach to scenery rarely fits into a perfect bucket or matches a single theoretical techniques. So here are some approximate terms, designed to generally describe an approach. They’re not going to be perfect fits, and even the definitions will fluctuate in different contexts and forums.
- We can say scenery is plausible when it looks like it might exist somewhere in the world. Plausible means that roads don’t go straight up over a cliff, trees don’t grow in the ocean, etc. In other words, plausible scenery is scenery where absurd things don’t happen. Plausible scenery is great when you don’t know what an area should look like. A lack of plausibility is often a bug.
- We can say scenery is realistic when it correlates closely with what is really present at a given location on the Earth. So if there really is a lake behind my house, realistic scenery has that lake. Plausible scenery might have a lake, a forest, or something else believable for where I live (the Northeastern United States). A giant sandy desert would not be plausible for my location.
- We can say scenery is procedural if the detail in the scenery comes from some kind of algorithm that produces results. For example, a fractal coastline is procedural.
- We can say scenery is data driven when the detail comes from some source of external input data. Our mountains are currently data driven – that is, the mountain shape basically comes directly from the DEMs we use.
- We can say scenery is artist driven if the look of the scenery comes from art assets created by an art team.
- We can say scenery is algorithm driven if part of its look comes from the transformational process that converts data from one form to another.
(I’m sort of drawing a line in the sand here with procedural vs. algorithmic, but what I’m trying to contrast is a program that generates ‘information’ out of thin air vs. a program that creates information out of other information. For example, in X-Plane 9, European capillary roads were procedural. We had no real data, so I wrote an algorithm that made them up in a manner that was consistent with underlying terrain. In version 10, these roads will be algorithmic; we take OSM data and then do some processing to make it suitable for X-plane. This is definitely a line in the sand kind of definition.)
So Are We Plausible or Realistic?
So the first question is: is the goal of X-Plane global scenery plausibility or realism? The answer is: a bit of both. Austin’s posts on the subject virtually always bring up plausibility. The reason for this is simple: he is not too worried about the amount of realism we’ve put into the scenery, but he is not happy with the bugs. He wants the bugs gone. So every time he and I speak, he says “and make sure it’s plausible!”
But we’re not going to remove realism just to fix plausibility bugs. I expect that the next global scenery render will be at least as realistic as the last – that is, we’re going to use better data and we’re not going to make up data where we had real information before.
There are limits to realism. We don’t expect the global scenery to ever be as realistic as a custom scenery package for a small matter. But realism does matter. Part of the joy of flying in a flight simulator is seeing the real world. Where we can have more realistic global scenery, we consider it to be a win, and we are always looking to be more realistic than the last render.
Plausibility for the version 10 render is going to take two forms:
- Bug fixes. Any time something screwy happens, it’s not plausible. Sometimes these are code bugs that must be fixed, and sometimes they are data conflicts. For example, the water data sasys “water” but the elevation data says “hill”. Combine them and you get water going up a hill. We have to write code to resolve this, somehow.
- We are reworking the way cities are rendered, because even at their best, the old approach, procedural buildings with algorithmic roads over land class photos, did not look plausible, even at its very highest setting. So this is a feature request to fix a plausibility problem.
Algorithmic or Procedural
I’ve discussed this before (and forgotten about the post). But to expand the discussion, we need to consider not only algorithmic and procedural data processing, but whether we are driven by procedural generation, input data, assets created by artists, or some combination. (In practice, all systems require a mix of data, art assets, and procedures and algorithms, it’s a question of the blend.)
I’ve been working on global scenery for a few years now, and over time I’ve come to appreciate the importance of artist input (via art assets) into any scenery process. Simply put, if you want scenery to look good, you need to make it reasonably straight forward for people who are good at making pretty pictures to control the look of your visual results. A few years ago I viewed the scenery process as strictly a question of data conversion and visualization, but now I see it as finding a way to merge art assets and data into a cogent final product, with the art assets being used in a way that the artists can control. In practice, this often means making sure that the art assets come in a format that artists are comfortable with or can learn without too much pain.
As I said in the previous post, our approach is becoming more algorithmic and less procedural as higher quality source data becomes available. (For example, we don’t have to generate European roads when we can import and reprocess them.) But our approach over time has always been heavily artist driven. By this I mean: our input data is algorithmically processed into a final form that makes sense only in the context of art assets, and we have a pretty good idea of what those art assets will look like when we design the algorithms. To use roads as an example again, our task with OSM is to convert OSM road data into a road network that will visualize nicely with road art assets created by an artist.
Procedural Compression
One way to view procedural scenery is “creating lots of information from little or no information”. But another wa
y to think of it is as a compression technology. As was correctly pointed out on the org forums, you use less storage specifying the overall location of a forest than you do specifying every tree individually. The compressed form (store the forest location) can be equally plausible. It will be less realistic if the original tree locations were based on real world data, but it will be equally (unrealistic) if the original tree locations were procedurally generated. Put another way, pushing procedural processes out of the scenery generation process and into the flight simulator makes DSFs smaller.
When I first started working on X-Plane 8 DSF scenery, not only was DVD size a factor, but so was load time; we had one core and it wasn’t a very fast core. Anything we could do to make loading faster, we did. Thus we pushed a lot of work into the scenery generation process, including procedural processes, to keep load time down.
Times have changed; we now have dual core machines as a baseline, and often quite a few more cores. Thus over time we are starting to move procedural processes back into the simulator, trading load time (which runs on multiple cores) for generation time and file size. So perhaps a more accurate statement would be: our scenery generation process is becoming more algorithmic and less procedural, and X-Plane itself is becoming more procedural. This is driven both by more input data (which must be processed up front) and more compute power on the host (which lets us shrink file size, and thus use DVD space for other things).
X-Plane 10
Here’s how this plays out in practice in version 10:
- Some (but not all) of the building placement work* has been moved into X-Plane; a bit of expensive precomputation is still done at DSF generation time.
- Some (but not all) of road processing has been moved into X-Plane; a lot is still done at DSF generation time.
- Where possible, we are moving from a multi-layered approach to terrain to a pixel-shader-based approach to terrain. This cuts down overdraw and uses the GPU more efficiently. (The simplest example: in X-Plane 8 and 9, cliffs have separate terrains from hills. In X-Plane 10, a single terrain sits on both the cliff and the hill and changes its appearance based on the actual slope; this texture change is computed by the GPU.)
In other words, X-Plane 10 is making the logical evolution to better balance the computing resources we have to improve plausibility and realism.
