Written by Bill Womack.
This is part two of our intro to X-Plane scenery design for FSX developers. In the part 1, we got our tools together, laid down an ortho image like a boss, and faced the good, bad, and occasionally ugly of X-Plane autogen. Now it’s time to turn our great start into an amazing finish.
Another thing that might be sticking in your craw right now is how blocky the road networks look. They’ve clearly been built to maximize performance, but would adding some smooth curves here and there really slow things down that much? Here’s your next good news/bad news scenario. Bad news first: although WED is an amazing tool, one thing it won’t help you with is editing roads. Fortunately, Overlay Editor is more than happy to step in and do that heavy lifting.
It’s decision time. At this point, you could get your roads looking just the way you want before going any further in WED. If you don’t think you’ll need to do any more edits to the roads after adding your airport, work on the same project you set up in WED. On the other hand, if you want to maintain the flexibility to edit roads throughout the project, set up a new roads scenery entry, make sure it’s on a layer below your airport package, and do your work there. The crux of the problem is that saving an Overlay Editor project over the top of an existing WED project can wipe out some of your WED work. I find it’s best to keep them separate.
Next up: now that we’ve got such a pretty ortho background, it’s time to start dialing in the airport itself; editing the runways, taxiways, etc. This is something you’d do in Airport Design Editor, for example, in FSX. In X-Plane, what’s the tool for it, you ask? WED, of course! It’s the Swiss Army knife of XP scenery tools. You probably already imported the default airport.dat file into your WED project, so you’ll see it projected on your ortho. Now it’s time to move those polys and vertices around to get everything lined up where it needs to be.
With the layout out of the way, the next stop is adding some good-looking custom ground polys. Every project I’ve done so far has been converted from FSX, so I already had my polys done as layered objects. For that reason, I’ve added them as draped objects to my scenery rather than using POL files, but either method works equally well. I’m going to focus on placing them as objects for this discussion.
Export your layered ground polys as objects, setting their draped attribute either in your 3D program or by hand in the resulting OBJ file. In the same way that you can specify layer ordering in ModelConverterX’s ground poly wizard for FSX, you can set layers and offsets for your ground in XP. Read up on layers in the OBJ8 file spec for more info. Likewise, you might want to add a specular or normal map to your object (see notes on 3D object creation below). Once the ground polys are ready, copy their OBJs and textures to your WED project folder. Then place the base layer where it needs to be and copy its lat/lon/heading. For the rest of the layers, place them using the location you copied so they line up perfectly.
By the way, although your custom ground polys will drape over undulating landscape, you might not want your airport to be hilly. If you find it’s too difficult to navigate the peaks and valleys on the field, you can always set the “always flatten” option for your airport in WED and it’ll smooth out the airport within the boundaries you set up. And yes, always set your airport boundaries for just this reason.
Okay, it’s a bit late in the article to discuss this, but here we go: making 3D objects. Mostly, this is the same procedure as you’d do in any sim, FSX included. There is one notable exception: the dreaded one texture per object limitation. At first glance, this seems like something bordering on a deal-breaker for FSX developers. After all, we’re used to being able to use multi-texture materials for years now. Fortunately, the more you investigate it, the less daunting this problem becomes.
The quickest solution is to create larger single texture sheets that incorporate your original FSX textures into one file. For instance, if you used four 2048 sheets for a large building in FSX, make a single 4096 x 4096 texture and grid all four of your original textures within it. You’ll have to scale your UV maps and reposition them, but this isn’t very time-consuming. After a while of working this way, you start using the one-texture rule for everything you make. The result is not only cross-sim compatible models, but reduced draw calls as well. Performance!
A word to the wise regarding X-Plane OBJ textures: don’t assume that because you’ve already got DDS files from your FSX project that they’ll work in XP. Yes, XP uses DDS textures too, but for some reason it seems best to run your original images through XGrinder to convert them to DDS for XP. Also, beware that it only takes PNG files as input, so you’ll have to pre-convert any images you use first. Unless you want to lose quality, always use your original source images (Photoshop PSD files in my case) to do the PNG conversion, and use the high-quality, slowest option when converting to PNG.
Maybe you’ve already been using some approximation of physically-based rendering (PBR) in your FSX projects via normal or specular maps. The good news is that this functionality is even better supported in X-Plane 11, and it’s very easy to work with. For a good overview of how to affect the glossiness/reflectance/specularity of an object, see this article: [https://iliastselios.wordpress.com/2018/01/17/x-planes-pbr-materials-a-simplified-guide/].
For ground polys, or any other object in which you want to have specularity but don’t necessarily want to use normal maps, the easiest solution is to simply create a grayscale image of the spec map with no alpha channel and save it as a PNG file. Doing so avoids the 50% red and green channels plus alpha shuffle and gets straight to what you want to do. Don’t forget to use the GLOBAL_SPECULAR attribute in your model if you choose to do so, though!
Now that you’ve got the most beautiful PBR-enhanced objects known to humankind, it’s time to place them in your scenery. For those who are familiar with the various object placement tools for FSX, can you guess which one you use for XP? I’ll give you a moment. Ready? WED!
Just as with your ground polys, copy your model OBJ and texture files to your WED project folder and start adding them like a maniac. The only word of caution here is that WED can be a little coarse in how it calculates locations, so if you need to move something by centimeters, it might be best to do it in your 3D program and re-export the OBJ. For that reason, I tend to model groups of objects at once in Blender and position them all relative to one another, then place each one in WED using the same coordinates. You might have to swap back and forth between WED and your 3D modeler a few times, but the level of control over placement is much better.
For some reason, I always leave night lighting for last, and this article is no different. It’s important for scenery to look good at night, but I find it’s easier to wait until everything is just so before lighting things up. I’ve also saved the best for last, because X-Plane looks flat-out amazing at night. The graphics engine is much more capable of dealing with light effects than FSX without bringing your system to its knees, and the result is unmatched realism after sunset.
Just like in FSX, you can always bake in the less important lighting and include it in your lightmap texture. In FSX, the old naming convention is “[texture name]_lm.dds”. In XP, they’re partial to “[texture name]_lit.dds”. Really though, it doesn’t matter what you call it as long as it’s specified in your OBJ by the correct filename. Just be sure to specify it correctly in whatever OBJ exporter you use.
The same goes for your orthophotos. To be honest though, the autogen night lighting is so good in XP that I’ve not even been making night textures for my orthos. That might change as I venture into more built-up areas, but it just hasn’t seemed necessary so far.
As for placing light effects, if you’re familiar with Prepar3D v4’s dynamic lighting effects, you have the basic concept down. The difference is that XP’s light effects don’t have nearly the detrimental effect on performance. Oh yeah, and there are several types of lights; named lights, parameter lights, and custom lights. What’s the difference, you ask? Sorry, I need to go take a Xanax before even talking about them.
It seems that the lighting system in XP has been the recipient of an endless stream of modifications over the years. Instead of just upgrading how things are done, they’ve kept the old ways and heaped several newer methods on top of them. The result is a tangled mass of confusion that can quite neatly explode the head of a newbie trying to figure things out.
In a nutshell, named lights are the easiest to use, but also the most limited. In a few instances, they’ll be perfect for you. Most of the time, not so much. Param lights are common in scenery, and can be useful for things like apron lighting, but so can custom lights. I’d love to say, “here’s a foolproof way to do it”, but this is one of those subjects that you’ll just have to devote a bit of Google time to learning properly. At this point, I’m still in the find someone else’s lights and copy how they did it mode. With a little massaging you can get them looking great though. Keep at it.
If you’ve stuck with me this far, good job - you have a future in XP scenery design! It can be rewarding seeing your work appearing in XP’s gorgeous rendering engine. There will be times when an experienced FSX developer will throw up their hands and say, “why is it so much easier in X-Plane?” There will also be times when you shriek the opposite. After doing a few scenery conversions, the one thing I can guarantee is that you’ll quickly start thinking bi-simually and your resulting work will get progressively easier to port to either platform. All it takes is patience, practice, and beer. Lots of beer.