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.
Cool post.
Question: You said if it’s too dark, just add more lights. Can you instead just increase the brightness of the light? And how much control do we have over lights? Can you/we adjust the color, heading, field of view, strength, etc. of the light?
If you use a pre-made lego brick, you get no control – the brick is pre-made.
If you make your own OBJ, you use a LIGHT_NAMED to add the spill, and you get _complete_ control over the light!
The library may end up with multiple light pole lego bricks for different patterns of cast light – I’ll have to talk to Tom about it.
This is amazing. And being able to use the tech to create custom walls is also fantastic as it would allow us to create customized looks for terminals (if I understood it right).
Besides instancing, are you taking any advantage of dual-GPU cards like the GTX590 on v10? Should we even care about having one?
Thanks!
Right – you could make your own terminals by building a custom facade and using it. Or just by modeling it with an OBJ.
Dual core GPU: we have taken no action to intentionally optimize X-Plane for dual-core GPUs or SLI. However, we haven’t intentionally tried to make it worse either. We simply have no idea what will happen. It’s really up to the driver…if the driver can make the card (Whether dual core or SLI) look like one big card with more fill rate, then you get a fill rate win, which _might_ be a win, depending on how high of a res you run and what rendering settings you have.
I can’t give you any buying advice about whether or not to spend money on such things.
This all looks very promising. I’ve never worked on scenery for a flightsim, but your posts certainly got me interested!
If I understood correctly, you will let users contribute their airport configurations and distribute them through X-Plane updates? This may be a fast way to recreate some airports, although developers may have to spend some time on quality control (and conflicts between different projects and users creating content).
That is correct. If a configuration consists only of standard X-Plane elements, we can merge it into the master database of airports and put it into the next patch so everyone gets it.
how much of all this new tech features for v-10 will be in default airports, scenery ( which we want to see what the new global textures look like) etc. shipping on dvd? vs giving us users the info for those who can and or care to make add ons etc..
basically will final end users whose sole purpose is to buy v-10 on dvd + download from .org and other places, get a same great experience from new art assets and features than those people who actually code , build and use WED?
?
I assume the DVDs will show 1 airport accurately set out as per LOWI Innsbruck in version 9.
Then by running the update program, a user will get whichever airports have been set out and uploaded by volunteers in the x-plane community up to that time. Over time this will expand.
Note that Robin Peel currently collects volunteer-uploaded flat airport data for use in X-Plane and any other simulator / map maker to use. ie it is open source.
These additional files sound like they will be for X-Plane use only…
Autogen Point scenes (.agp files), would be used for covering areas like carparks, were you need lots of repetitive files and has a basic constructive base of say cars, vans, road (parking) lines, trees around the edge, car rental office and so on, and you then just drop it in.
I am glad we can change the facades of the terminals, it will give us a lot more movement than having one design that i feared would be right through the system.
I used to be a lego master, so here i go again……brilliant
Yes, the .agp file format has particularly caught my eye. It has some of the hallmarks of a request I made a couple of years back to be able to incorporate objects within objects.
Ben,
Does the .agp format allow the designer to define the vertical placement of an object’s origin with the scene? I’m thinking of the ol’ classic scenario of car objects on different levels of a multi-story car park object.
No vertical placement of OBJs in AGPs at this time. There will be vertical placement of OBJs in the sim itself though – by MSL. We may add that at some point. Now that we have instancing some of our aversion to modeling with small objects may go away…we’ll have to see. Facades can spawn objs on their roofs, and they can have multiple level roofs for car parks. 🙂
Great news Ben , any chance you’ll release those new features specifications before X-plane 10 is published?
The file formats aren’t “final” until we go gold, so I’m at least a bit hesitant on how much preliminary info we put out. When v10 goes gold, everything we have internally (our internal wiki with authoring notes, our blender scripts, etc.) will go public. Work on the scenery tools code base is already open source – that is, if you want a DSFTool build that can write MSL-placed OBJs, you can just compile it yourself.
Some file formats have no spec outside the x-plane code. For example, the facade 2.0 format uses 3-d meshes, so it’s only practical to create them with a 3-d modeling tool (we use blender 2.49 for this). So I never wrote a clean spec – the docs are in the code itself. So I’ll have some post-ship writing to do.
Other features come from the published RFCs on the wikis, although some may be changed a bit in implementation.
If there is a particular feature that you’re looking for compatibility with, let me know, but I don’t have time to put together comprehensive docs before we ship – too much has changed! With all of the above resources, finishing that “SDK” once we ship shouldn’t take very long.
Looks like Ill have the ability to finally do a PAAQ. One of my favorite destinations in XP. Thank all of you for your efforts this is very exciting!
Interesting! I’m especially anxious to see how the draped geometry in OBJs works out. It sounds similar to a feature that I was beating on MS to implement in their FS series for years, to no avail.
Hi Bill! 🙂
It should work pretty well – it’s the same “draping” tech (chopping and then deforming a polygonal shape to the terrain mesh) that we use in the .pol files and runways. The difference is that, because it is attached to an OBJ, it’s way easier to use them – you just model and drop them. And since they are attached to an OBJ, the registration between 3-d and 2-d should be accurate.
I see a couple of mentions of Blender being used for creation of these new scenery files. Funnily enough I was considering switching from Blender to AC3D for my next scenery project because I was finding keeping track of the disparate development directions for Blender 2.5.x and XPlane2Blender hard going and had assumed that the whole Blender ecossytem would be slow to catch up with all the new v10 features.
But maybe this is not the case? Conversley, where will the AC3D plugin be at with regard to supporting these?
Well, Blender is sort of forked – because you can’t write a script for both 2.49 and 2.5 there are now two fully functioning separate code streams – the 2.49 stuff – it starts with Jonathan’s script and then there are a few forks – mine, Ben R’s, and I think Dan may have a separate one. Then there is the fully separate, ground-up 2.50 script, which is not forked.
Anyway, here’s the v10 situation:
– Internally we use Blender 2.49. We have new exporters for the AG, road and facade asset formats. We have a mod of my code fork for OBJs with v10 features.
– We will release all of our 2.49 scripts when 10.0 ships. We can’t guarantee support for the non-OBJ stuff – the AG stuff in particular is super-tweaky, but you’re welcome to try it. Some of the scripts are specifically tuned for our work flow, so I’m not sure how generally useful they’ll be.
– I will leave it to others to support v10 OBJ stuff in other Blender code forks including 2.50, but I am always happy to help people by answering questions, and the code is GPL, so anyone can have it.
– I will update ac3d to do OBJ10 stuff when I have time, but I am not planning on setting ac3d up to do other art asset formats (like facades).