FSX:SE Scenery shows in P3D V4, but some are missing in FSX A

Hey all,

As it says on the heading, my scenery pack I have been working on shows up excellent in P3D V4, but not in FSX Acceleration.

hmmmm... :(

Anyone have any ideas what it might be? Works brilliant in P3D V4.

These scenery parts that I did in the past 2 days, they are small. No huge mountain ranges. Just small mountain parks. Very small. Smaller then medium sized airports. Very odd.
Hi Bill:

What type of "mountain parks":

* Custom photo-real land class imagery ?

* Terrain Mesh ?

* Both ?

What is the resolution of the above BGLs when inspected in SDK TMFViewer ?

What is the resolution of the Terrain mesh and/or Texture sliders in FSX GUI ?

Hey Gary,

Its only Photoreal tiles, created with SBuilderX, low resolution. I just maxed out my texture resolution (it was at about 50%) and the missing zones are still missing. So thats not it.

I didnt log the zoom level when I pulled the files from online. So I have no idea what zoom level its at. I know its not high as they are just little hills. Not big.


This is a couple of the large hills that are missing. This is taken in P3D V4.5. They are on each side of the wingtips, just below. Not showing in FSX-A.


I am thinking of trimming them down, cutting the houses out so they blend better with the stock scenery.
Hi Bill:

The FSX Terrain rendering system for custom photo-real imagery BGLs requires that downloaded imagery tiles be at least Zoom Level 15 so that when compiled by SDK Resample, they will be at LOD-13, and thus capable of being displayed on top of default land class.

A good way to do this in SBuilderX is to set the work-space with the imagery background Zoom level at 13, then in the Add Map > From > Background tile down-loader dialog, 'select' by dragging a Green rectangular 'frame' around only those tiles wanted, then assign them to be downloaded at ex: Zoom level 15 or greater.

BTW: With FSX sliders for terrain mesh and textures all max right, you will more accurately be able to work with scenery.

Let me know how this works for you. :)

Last edited:
Ok, here's what I got. I usually pick the option of 17 as the tile scale setting, and did that. At zoom 13, I could barely see the mountain with 17 as the tile scale setting, tons of tiles and the size on my big screen was zoomed out radically far, at 13x zoom level. I usually zoom in farther to see what I am getting and select the tiles better.

I took the image, viewed it, and its identical to the one I took before (nearly, basically, identical resolution).

Also, I went into the texture bitmaps and noticed that they all start with '17x'. Would that denote that these are screenshots at 17x scale/zoom? For instance, on this one I just tried, its original bitmap background is named: L17X49328X49347Y104960Y104975.BMP I take it that perhaps its 17X scale?

Also, when doing these the other day, I noticed I wasnt saving the TIFF's as single layers. I began saving as single layers later as I was working. Just now, earlier today, I redid the textures (SBX exports) with flat TIFF's and that made no difference on visibility issue in SFX. Still showing fine though in P3D V4.5, and always had. Perhaps SBX doesnt care if the TIFF is flat or not, only using it during the generation of the masking during compilation?


Also, is there a way to look up the texture name in your saved SBX file? I have looked around and cannot seem to find it. I looked in properties, etc. Surely I am missing it, or perhaps its hidden?

I have been hunting them down by matching the view with maps.google.com to see what it looks like (memory refresher) and clicking the tiles that look similar..
Hi Bill:

For info on how a composite L[?]X[?]Y[?].BMP filename is derived from a work-space background map tile mosaic, see:


Are you manually editing the SDK Resample *.INF file output by SBuilderX along with the L[?]X[?]Y[?].BMP file ? :scratchch

If you post the *.INF file "code" text for the example source file set shown in your above attached erdwsz.JPG:

...we can verify it is correctly identifying the intended Masks as Channels in that *.TIF and/or *.BMP file set.

As you may know:

* BMPs can have only (1) Alpha channel

* TIFFs can have (1) Alpha along with multiple other channels

The *.INF tells SDK Resample which files- and/or channels within those files- are to be regarded as Mask data

Depending on how you structured the data in 'layers' (aka "channels") within your *.TIF or *.BMP


Depending on how your *.INF refers to the data in 'layers' (aka "channels") within your *.TIFF or *.BMP

...you may-


* you may not-

...need / want to "flatten" (aka 'merge') layers (aka "channels") within your *.TIF or *.BMP:alert:

IMHO, it is easier to work with custom photo-real when each source file type has only (1) channel. :idea:

But with your advanced experience, you might also find it preferable to work with many layers in ex: PhotoShop: ;)

The above example by Bill Womack shows use of many layers in PhotoShop (in this case, for 3D scenery objects)

Last edited:
Hey Gary,

Many thanks for your patience and detailed help and trouble shooting.

I cannot seem to find any INF files. I am also not working with changing the landclass, only putting some ground textures down, nothing more. Texture, and a set of _B (blend) and _W (water) masks, which I thought were necessary if you do a blend, that you also need a water mask as well, and that SBX automatically blends them together. And it does. Good so far. Fine control on blending. I can also leave them out. So... No INF files. Nothing found in that area in the entire SBX folder system. Nothing that I have created/generated.

I wonder... Sometimes when I 'start' a new project, I start the project with a fake name, then when I have produced the package, I 'save as....' and add the proper name. I figured that for some reason, it asks for a name, but its not using it, not saving it until I have created maps and things. Then it has something to save. But when you first go to start a new project, it asks for a project name and there is where I started just typing in some jibberish to 'get the ball rolling'. Could that be where I am going wrong, I wonder?

EDIT: Why I figured this (not being saved) is there is no SBX file saved until I 'Save as...' and put in a name, then the SBX file with name is then saved. Jibberish temp names are not there. SBX names I 'save as' are..

Also, no changes to the BMP's. Not editing their sizes, etc, as I figure that will destroy their tile location system.
Last edited:
Hi Bill:

It would be a good idea to first name a project in SBulderX, and then 'Save' that *.SBP project file before proceeding.

SBuilderX will then auto-save the project at intervals specified by editing a parameter value in the SBuilderX.ini file.

I suggest setting the interval no closer than every 5 or more minutes to minimize the number of separate *.SBP backups written into a folder. ;)

NOTE: Although "SBX" is often used as an abbreviation for SBuilderX, it might be best to instead use ex: "SBX315", as it would avoid confusion in forum posts when read by newcomers, with *.SBX SBuilderX Exchange files ...which when 'exported', internally store all 'scenery builder' project data except the externally stored downloaded imagery tiles (...somewhat like a ADE *.AD4 project file does with 'airport' source data).


FYI: When a background map is 'selected' in the work-space for compilation into a custom photo-real imagery BGL, SBuilderX outputs:

A *.BMP 1-piece file copy of a 'selected' imagery tile mosaic (the "composite L[?]X[?]Y[?].BMP" cited above (Raster)

A *.TXT Geo-referencing 'world' file ( ASCII Text; DO NOT EDIT THIS FILE ! )

A *.INF SDK Resample file (ASCII Text)



[SBuilderX install path]\Tools\Work

These are the minimum files required for SDK Resample to generate a custom photo-real imagery BGL file.

Use of Blend / Land-Water Masks, Night / Seasonal variants is optional, but when they are intended to be used, each source file for these options must be listed in a *.INF.

Its true that SBuilderX 'can' find source files for a particular project source data file set and 'automatically' add them to a *.INF, however this requires a specific and explicit source file naming protocol to be followed for a tile image 'Map'.

Each source file must be explicitly named in a *.INF. and any blend data must be explicitly defined as to the source channel it will be read from (...as 'data' rather than as an image per se).

Otherwise, SBuilderX may gather *.INF info via a 'mix' of files, and fall back to a internal Blend Mask "border" file: :yikes:

[SBuilderX install path\Tools\Work\blendmask.tif

By default, when a background map is 'selected' in the work-space for compilation into a custom photo-real imagery BGL, SBuilderX outputs a *.INF with a "Photo[??]" file name into:

[SBuilderX install path]\Tools\Work

The sequence in which SBuilderX assigns a "Photo[??]" *.INF "Map" file name numeric digits, is based on what other "Maps" may have previously been output into:

[SBuilderX install path]\Tools\Work

...during that same work session.

NOTE: The "Map" name is distinct from the SBuilderX project *.SBP file name and the composite *.BMP file name. :pushpin:

The "Photo[??]" *.INF for a "Map" contains instructions with a list of source files for processing by SDK Resample ex:

A *.BMP 1-piece file copy of a 'selected' imagery tile mosaic (the "composite L[?]X[?]Y[?].BMP" cited above)

A *.TXT Geo-referencing 'world' file

A *_B.TIF Blend Mask (8-Bit 256 gray-scale step)

A *_W.TIF Land-Water Mask (8-Bit 256 gray-scale step)

Optional variations:

A *_LM.BMP "Light Map" aka 'Night' variant

Multiple *_??.BMP Seasonal variants: (in this context, *_?? refers to a 2-character abbreviation for FS 'season' images)

*_Sp.BMP = Spring Seasonal variant

*_Su.BMP = Summer Seasonal variant

*_Fa.BMP = Fall Seasonal variant

*_Wi.BMP = Winter Seasonal variant

*_Hw.BMP = Hard Winter Seasonal variant

CAVEAT: If working with source data to be compiled by SDK Resample into custom photo-real imagery land class:

* SDK Resample cannot output BGL files larger than 2 GB in size

* SBuilderX 'may' have a 'working data set' size limit that is smaller than 2 GB, for source files processed and submitted to SDK Resample

BTW: A quick reminder as to whereabouts of a couple of previous threads in which we discussed some of these topics:



Also, if I had not mentioned this in our prior communications on these topics, you may enjoy reading this fine tutorial:

Make photo-real ground textures

File Description:
It is very easy to create your very own high-resolution, custom (photo-real) ground textures. This document explains the concepts and techniques and illustrates the use of SBuilderX with which you can quickly and easily download aerial images and make this type of scenery. So, why hesitate? Make Flight Simulator scenery as real as it gets! Very sorry - no support of any kind is offered. Please do not write. For any questions, please post in the Avsim Scenery Design Forum.

Filename: make_photo-real_ground_textures_in_fs_x.zip
License: Freeware
Added: 21st November 2009, 23:20:06
Downloads: 17714
Author: Luis Feliz-Tirado
Size: 2143kb


For a convenient way to ensure Geo-referencing for a project work file set is maintained, use Ollyau's GeoTIFF to INF:


GeoTIFF to INF tests a GeoTIFF file to verify it has a GIS projection required by SDK Resample, and outputs a *.INF

Geo-referencing for a GeoTIFF source file is listed in parameter values for it in the *.INF output by GeoTIFF to INF .

Geo-referencing of a GeoTIFF can be copied / pasted / edited for other source files copied / edited from the original

One can thus keep Geo-referencing for a each source file in a project work file set inside a *.INF ...by each listed file, provided that we do not change the total number of pixel Columns and/or Rows while editing it.

NOTE: One can edit copies of *.BMP 1-piece composites of 'selected' imagery tile mosaic (the L[?]X[?]Y[?].BMP"). :idea:

But, when editing copies of such source imagery files, do not change the total number of pixel Columns and/or Rows.

That will keep the original Geo-referencing for the images as contained in the *.TXT 'world' files.

If one wishes to change names of source files in a project work set, the names must also be changed in the *.INF file

When all files are ready for compilation, one can drag-and-drop the final *.INF onto SDK Resample

Hope this helps to clarify requirements- and options- we have working with SBuilderX and SDK Resample. :)

PS: As an experienced FS Developer, you probably know all too well that files seem to multiply and hide from us if we are not looking < like clothes hangers in the closet do ...but only when the door is closed and the light is off ! :laughing: >.

A useful and well-written tool that I have used for years to quickly find files on all my NTFS drives is "Everything":



One could install that local search utility, wait for a brief indexing process to complete, then enter this query:


A 'lightning fast' result would list all "hits" for that file extension ...on all NTFS drive on ones computer. :wizard:

Last edited:
For others that might be having issues finding the INF files, note that SBuilderX uses TXT files for that. It generates them in the area where it stores the BMP, usually the SBXxxx/Tools/Work folder. From there you can add sections for other features that your scenery will have, such as night maps, etc. When you create your first scenery in a project, the accompanying TXT file will have the base data in it concerning where the terrain is in the FS world, coordinates of the points of the map.

Do not start scanning through 12 different hard drives for INF files. You are looking for TXT files with identical names as the BMP's will have which is the name that SBX autogenerates.
Hi Bill:

Indeed, as I endeavored to further clarify by my 'edits' above:


The Photo[??].INF 'text' file for a 'Map' composite tile image can be manually edited after generated by SBuilderX.

The *.TXT Geo-referencing 'world' file of course, should NOT be edited.

And indeed, there are LOTS of *.INF files on a Windows installation which might confuse newcomers to this work-flow;
I used *.INF as an example to show how to use "Everything" local search utility knowing it 'could' prove useful to you.

PS: Although one 'may' be able to get SBuilderX to find and use properly-named source files to create a more complex "multi-source" *.INF, more likely such a multi-source scenario might require manual *.INF editing and processing by SDK Resample, rather than utilizing the built-in named composite image 'Map' system via SBuilderX GUI. :)

Last edited: