I spent a few hours last night working on X-Plane’s facade engine – that is, the part of X-Plane that builds buildings, fences and structures from their shape traced on the ground. Besides fixing some v9 compatibility bugs, I had a chance to add in a few last features that didn’t quite make the 10.00 cut.
I used Tom’s “classic”-style parking garage (you’ve seen it – it’s the one used at KSEA in the demo area!) to test some of my work; some of the work on the facade engine illustrates three different ways to optimize a program.
Be More Efficient
The first way to optimize is to find ways to accomplish the same work in less time – that is, to write more efficient code. This is certainly the least risky form of optimization: there’s no trade-offs, you just get more for your hardware dollar.
In the case of Tom’s parking garage, after putting geometry in place for the roof of each floor (to fix a rendering bug) I noticed that we were building the mesh for each floor twice – once for the roof of the level and again (but facing in the opposite direction) for the floor of the next level. I added some code to the engine to recycle the mesh, but create duplicate indices; now two-sided roofs in facades use about half the vertex count.
There are still a number of places in X-Plane 10 where we can be more efficient. But rewriting code to be better takes time; these performance changes will come out incrementally, and any one change may not be that noticeable. What is important though is the net effect of improving efficiency over and over again.
Cheat!
This sounds negative, but when it comes to computer graphics, cheating is preferable. Clouds behind the panel? Just cheat – don’t draw them! Trees too far away? Use a billboard! No airplanes in the game? Use a painting for the sky and don’t bother with 3-d clouds. What I am referring to here is finding ways to deliver the appearance of eye popping graphics for significantly less work. This kind of optimization is critical to making a competitive rendering engine.
In the case of Tom’s garage, the facade engine puts the same number of cars on every level of the garage. This is hugely wasteful; while you might want cars on the roof, you don’t need very many on the lower levels. The lower levels are only visible from the side, and from the side even a few cars are enough to create the appearance of a non-empty garage.
So I am adding to the facade engine the ability to specify mid-level objects and roof objects separately; Tom can use that to “thin out” the objects in the garage. The result will be a big reduction in OBJ count for almost no visual quality loss.
I think there’s a lot of fine tuning we can do like this to make sure that we spend our hardware budget only on things that really matter most.
Scale Down
This isn’t really a type of optimization, but it’s important to make sure that the rendering engine can throw visual detail out to meet the requirements of older computers. One of the problems with X-Plane 10 is that some parts of the rendering engine only have one mode: “maxed out”.
10.04 beta 2 will allow facades to specify attached objects (like the cars on the parking garage roof) that decrease in density with the rendering settings. The result will be a full garage when objects are on “insane” but a mostly empty one with just a few cars when objects are on “default”.
Tom and I are working to put this kind of object density control in all of Seattle (as well as the airport library it uses and the rendering engine components that the library uses); the result should be a Seattle demo area that becomes significantly cheaper when the rendering settings are dialed back just a bit.
Ben – One thing I’ve noticed with the later builds is that one form of “scaling down” optimization appears to be a reduction in the max visible terrain geometry distance. While there was a bit of a bug I discovered with this, when the bug was not affecting my view, the distance we could see was exceptional. Now satellite imagery seems to be appearing much closer. Can you comment on that?
I don’t think there’s any change – we had that locked down pretty early in the private beta.
That’s good….I think! I’ll do some digging and see if I can duplicate the difference. If I find something, I’ll file a bug report. Thanks!
Cheating – finally! That has been the corner stone of the computer graphics/gaming for ages so I am very happy that you start using that path. I’ve created couple of complaining posts in the .org forum quite some time ago about this and am glad to see, that we are on the same page now 🙂
Thanks for this Ben, looking forward to the new beta.
Btw have you had chance to consider the possibility to have ‘draped/non-draped’ facades as optional?
Regards,
Premek
Yeah, more on this soon!
“the result should be a Seattle demo area that becomes significantly cheaper when the rendering settings are dialed back just a bit”
I’m guessing (or at least hoping) that this is going to be tied to the Airport Complexity setting and not the Global Objects density setting?
No, it will be global objects, I think. The long-term goal is:
– Objects: affects density of all kinds of modeled 3-d
– World level of detail: affects how far out all 3-d goes
– Forests: affects density of forests
– Roads: affects detail of roads
– Airports: affects detail of the airport _ground_ markings and pavement.
That’s the theory at least. Airports can be set up so that at low object density only the _essential_ elements are in place, then in priority order more 3-d comes in. The big divide is between instancing-capable cards (DX11 + some ATI) and not; the instancing-capable hardware has a much higher OBJ density; often you can max them out. Without instancing, you have to dial back objs and/or 3-d distance.
Over the last week I have been trying to find a set of settings that will give me a place to have a standard set of settings to level from, but it is a bit like dealing with Quantum Mechanics, it is the same but gives different frame rates every time, The same scenery, aircraft with no variables (weather, A.I. HDR all off), At one point i get 25-27fr, then the same will give me 6-7fr, same situation, same saturation of objects and very different results, then try to get the frame rate up and you can be a zero on nearly every render setting and still only get a 2-4fr return, restart and you are back at your former 27-25Fr, so i can fly perfectly happily one day and be dogged down the next, without changing anything.
Textures are hard as well, the gap between high and very high seems like a gulf, even if you pull every other render setting back to zero it doesn’t have virtually no effect, high is very jaggy, very high is perfect but unusable, even something in between would be acceptable, extreme textures just crashes the system, so why have it?
I could always find a level base to which i could adjust settings in XP9, but in XP10 I seem to be always on shifting sands and have nothing i really am happy with what i am looking at, and yet at times it comes into perfect focus and with the right frame rate….
Thanks for the insight.
When you are down to these stages of optimization, it seems to me that this is rather about optimizing the first impression (in the Demo area) than of the overall game. Where, besides parking garages, are these optimizations going to be relevant? In a handful of buildings, maybe. Once the scenery builders actually go back and change the objects to use the hints that are offered.
Well, first, any optimization to common art assets affects everyone. So optimizations that apply to the autogen, base terrain textures, roads and airport lib will apply outside the demo area. (The KSEA demo area’s parking garage, for example, is the default library one.) And some optimizations will be engine wide. But you are right; some optimizations don’t have kick until third parties adopt them.
Not to stray off topic, but was wondering when we might start seeing at least some building at airports other than the “demo” area?
Another potential big win would be in OpenSceneryX, but currently not with facades – there are only two of them in the library (well done Jonathan! 😉 but even these don’t make use of either of the optimised features mentioned above. I’ll keep an eye open here for any new optimisation options being implemented for objects, lines, polygons or forests, in case there are opportunities for tweaking OSX objects.
Certainly once I get some dev docs out there will be guidelines to make sure OSX objects hit the fast path.
As a hack, I downloaded that downtown LAX conversion – it’s heavy for my Mac, but went from 12 to 14.5 fps when I replaced the ATTRibutes used with their optimized v10 equivalents…that’s a 20% fps boost for a little bit of search and replace.
Great that you’re able to start fixing such things now Ben. Ha, the doubled ceiling/floor and too many cars reminds me of when Chip built a large building in sketchup
Once. It had a horrendous poly count, common for him, but off the scale. Close inspection revealed he’d placed dozens of those sketchup people, hidden in different parts of the building! Each one is worth, like, 10k verts. Then I found he used some sort of ornate door handle for ALL the doors. I felt like I was playing Doom that day, I erased a lot of ppl..
Yes, all this work is worth it so us 3rd parties can build efficient facades etc. can’t wait to find out how to customize the autogen for local areas too, so we can mix up those lovely residential and commercial buildings.