Skip navigation

Tag Archives: Scenery



Every piece of expository writing needs a good opening line. Unfortunately for you, dear reader, there isn’t one for this tome. Nevertheless, I feel the need to codify a couple of sentiments regarding my scenery products.

First and foremost, my self-identification in this hobby is “pilot”. Starting almost 3 years ago with a pretty specific plan, my goal was to become a virtual pilot. Even before starting detailed sim training, it was evident, that to accomplish my goal, I would need a simulation cockpit. So design and build on the pit started very early in this virtual pilot’s career.

What I did not foresee, was the need for sceneries. In my naiveté, I assumed that anyone that wanted to be the best virtual pilot would follow the same educational track as the real world’s best pilots. (There is probably the equivalent of an academic thesis to be written on this subject, but, hey, I would rather be flying.)

To be fair, many of the sceneries existed in an older version of the simulator. These scenery products were juusst compatible enough and juusst descriptive enough for use by the casual pilot in the current simulator version. But those early versions did not satisfy the training needs of a more serious (read: obsessive compulsive) virtual pilot.

Armed with college education in mathematics and cartography, honed by 2 decades of professional work in digital photogrammetry, I dug into existing sceneries and found some good mentors/websites. The existing scenery development community is at a very high state of knowledge and technique. As a result of all these factors, it has been a seductively easy process for me to create sceneries, almost too easy.

But for you, dear reader and possible user of my scenery projects, there are some downsides. Ultimately, these sceneries are designed as training aids for my curriculum. And are freeware training aids at that. You will not see the inside of buildings modeled in my projects (a possible exception might be a hangar). You will see the best FCLP operations I can manage.

The most significant disconnect between my scenery projects and the community as a whole concerns AI and static objects in the scenery. Candidly, I admit to stoking some of this tension, again, by my naiveté and inexperience in the community. The previous version sceneries mentioned earlier were designed specifically for the purpose of AI and had become the gold standard of those sceneries for the community. Even though, the taxiway striping was incorrect, even though they had no FCLP capabilities, even though they did not have ATIS, etc etc.

And here is the “however”….I am not going to do AI or conversion of AI. There will likely be almost no custom static aircraft in any of my projects. It is an area of knowledge that does not meet my goal. Again speaking candidly, autogen will likely not make the cut either. Luckily there are community members who have volunteered to contribute autogen so that the final scenery project will be more like a general use product.

We can debate whether AI is a training requirement or not, in theory, but in my scenery projects it is not. For my training, I use online flying for ATC and interaction with other aircraft.

I am not opposed to making systemic changes to my procedures that facilitate the creation of AI by other contributors. I am VERY VERY happy to include the work of other community members in my projects and to help fully integrate them as integral working parts. But I am not the end user of these features.

All of my scenery projects have been community efforts. Despite all of my mapping/cartography/IT background, I am still very much a flightsim n00b. The feedback from all of you, whether specific pointed comments, casual conversations, or open forum posts, has been an integral part of the project process for me. To state it as explicitly as I can:

I do not have the real world experience to create the training products needed to accomplish my goal of becoming a virtual pilot. I will trade you my cartographic skill and time in return for real world knowledge of places and procedures. I will trade you my cartographic skill and time in return for knowledge of FSX and procedures. With all of our backgrounds combined into one of these scenery projects, we can create the best possible training aid AND general use product.

Level of detail (LOD) modeling is the capability to have different models of an object drawn for different viewing situations. The most common use of this technique is for rendering simpler models at a larger distance from the viewer and rendering more complex models when the viewer is closer.

Here is a video of a popular FSX AI aircraft model that shows the various LOD’s.

The larger the LOD number, the more complex the model. The smaller the LOD number, the less complex the model. In FSX, the LOD numbers are interpreted based on the display resolution of the sim. For example, when the aircraft in the video is at a distance such that it takes up 575 pixels of the screen, then the LOD 575 model will be the one displayed. If the aircraft is very far away and is only showing as 14 pixels, the LOD 14 model is the one displayed. There is a very noticeable performance advantage when properly configured LOD models are used. As an object gets smaller on the screen, the processor does less and less work.

The opposite of this is apparent with many add-on sceneries for FSX or trying to use a non-LOD modeled aircraft in multiplayer. What happens is an immediate performance hit as soon as any part of the scenery or airplane comes into view, no matter how small or far away.

Here is a comparison of the LOD models for the big hangars on our Lemoore scenery:

KNLCHangarLOD400Full detail model to be drawn when the object is 400 pixels in size

KNLCHangarLOD100Reduced detail model when the object is 100 pixels in size

Note how much less work the CPU of the computer has to do for the LOD 100 model, 100+ triangles to be drawn,  vs. the LOD 400 model, over 1500 triangles. Also, there is a null LOD. If the pixel size of the object is less than the null LOD, it will not be drawn at all.

LOD models have to be tailored to the final size and complexity of the object.

KNLCHotPitLODThe hot refuel pit is a small, complex object

If the LOD models are not carefully tested, the object can appear to “pop” into the scene, or to radically change from one level of complexity to another in one short movement of the viewpoint.

Fortunately for this nugget, the tools for properly computing and transforming the LODs are already built. We just have to learn how to use them properly.


There is an old saying “The more you learn, the less you know.” This has certainly been the case for me with the KNLC Lemoore scenery project. What initially was an exploration into why a certain Lemoore scenery package was so hard on my computer performance quickly transformed into a 6 month journey learning FSX scenery design and has ended up with a full scale, major airport scenery for FSX. Typical uchi, cannot leave well enough alone.

So, at this point in the project, we are almost ready for an open beta distribution. All the detail we had planned to include (and more) is in place and there is a mechanism for switching between a high detail and a high performance version. Here are a couple of overviews of what is included:

 KNLCOpAreaParts of the Operations Area in this version

Our intent was to include parts of the OpArea that were visible from runways, taxiways, and ramps in this version “1.0”. Version “1.5” could have the remainder of the OpArea detail.

KNLCOutlyingArea Outlying areas from the main airfield in this version

I included several of this areas primarily because they were educational exercises for my scenery construction skills. But they do make the eastern approaches more interesting.

When we said the open beta was “almost” ready, in fact, some of the most technical work is in our lap. This work is reviewing all the objects, making sure that they are optimized for performance and have all the necessary elements for display.

The most significant part of optimization is reducing drawcalls. The more drawcalls, the harder the computer processor is worked. Reduce the drawcalls and increase the overall performance of the scenery.

Initially we were quite proud of our custom hangar designs for Lemoore (truth is, we still are). However, as we have gotten deeper into scenery details and expanded the scenery boundaries, it became apparent that those hangars were some of the largest producers of drawcalls. Work over the last couple of sessions has very much helped this issue.

KNLCHangarPreOptHangars in the closed beta

KNLCHangarPostOptHangars in the current version

Note, in the optimized version, we not only have 500% less drawcalls, but we also have greater detail. All of this improvement is about proper assembly of the various individual texture elements of an object into a single texture sheet. It is nearly impossible to do this when first designing a scenery object. Only after all the texture elements are in place, can the optimized single texture sheet be designed and assembled. With that texture sheet, the object must be re-textured in CAD and re-exported to FSX. There are 6 of these hangars in the scenery. This was 30 drawcalls in the closed beta version, now 6 hangars equal 6 drawcalls.

With this optimized texture, the performance improvement to drawing the hangars in the scenery is about 3x quicker.

Bear Studios SU-33 at LemooreScenery in sim

Stay tuned next time for more optimization talk: “Stuck in LOD time again”.