Until now the scenProc tool could only be used to create AGN files. But when you want to enhance or view existing AGN files it is also useful to be able to import them again. That feature has been added to the development release versio now. To illustrate how it works I will explain two use cases where this new step is used.

Enhance existing AGN files

Let’s assyme you have made some autogen files before only containing forest polygons. You used a file like this to create this autogen:

IMPORTOSM|schier.osm|*|*
#
SPLITGRID|AGN
#
CREATEAGNPOLYVEG|FTYPE=POLYGON;landuse=forest|{e8b937fd-a1f2-4bd5-8548-2c80d30102af}
#
WRITEAGNFILES|FSX|c:\flightsim\fsx\myscenery\texture

And now you want to add autogen buildings to the same area as well. Of course you could run the entire process again, adding more rules. But now you could also import the existing autogen and add only the new buildings. This is a configuration file that would do that:

IMPORTOSM|schier.osm|*|*
#
IMPORTAGN|c:\flightsim\fsx\myscenery\texture
#
SETAGNBUILDINGHEIGHT|*|1.0;0.0;0.0;0.0
#
SPLITGRID|AGN|building=*
#
CREATEAGNGENBUILD|FTYPE=POLYGON;building=*;FWIDTH<20|{5ae04eb6-934c-4f63-bb48-5e7dee601212}|MAXRATIO=2
CREATEAGNGENBUILD|FTYPE=POLYGON;building=*;FWIDTH>20|{6089A0BD-CED1-4c47-9A9E-64CDD0E16983}
#
WRITEAGNFILES|FSX|c:\flightsim\fsx\myscenery\texture

What happens here is that after loading the source data, you also load the existing AGN files. This means that all autogen defined in there is added to your data cells and when you create additional autogen it will be added to what is already there. So when you export it agian you have the old and the new autogen.

Export AGN files

How scenProc normally works is that you load vector data, this is then stored as internal vector features. Using the different steps you then create autogen objects out of these. In the example above the autogen objects were imported again, but in that case they are not converted to features, they stay as autogen. If you want to export the AGN to shapefiles for example, you would have to convert them back to features. This configuration shows how that can be done:

IMPORTAGN|c:\flightsim\fsx\myscenery\texture|CREATEFEATURES
#
MERGEGRID
#
EXPORTSHP|*|my_agn

The additional CREATEFEATURES option tell the tool to make features again. And these can then be export to SHP. The MERGEGRID step is optional, but what it does is the reverse of the SPLITGRID step, it combines all different cells into one big cell. This means you get one SHP file for the autogen, else you would get a SHP file per tile

Last week I got approached by different developers with suggestions for ModelConverterX to create flattens. So given multiple questions about the same subject I was trigged to look into this issue. Since I mainly create scenery for the Netherlands I have never had trouble with flattens myself. I think in the Netherlands you would even get away without any flattens, since the terrain is already flat.

But in more hilly or mountainous areas the problem is that FSX airports have to be flat, so a flatten is created for the airport. But if the terrain around the airport has quite some elevation differences, you are likely to end up with your airport on a plateau or other undesirable results.

By creating a sloped flatten you can usually make a more gradual transition from the airport to the surrounding terrain. Tools like SBuilderX and ADE allow you to create such flattens. But finding the correct elevation for the points can be tricky.

With this new functionality that will be available in the next development release another way to create sloped flattens is possible. You can now model the terrain shape in your favourite 3D modelling tool and convert it to a flatten with ModelConverterX. What this functionality does is create a sloped flatten for each polygon in the model.

Simply model the shape you want and export it to a MDL file. Then you import the MDL into ModelConverterX and enter the coordinates of the reference point. Next under export scenery you will find the new format “FSX flatten BGL file” and this will use shp2vec to create the flatten BGL from your object. Below is a picture where I turned one of my test objects into a flatten (I know, this is not a useful terrain shape, but it demonstrates the concept).

I am not sure yet how easy it will be to model a shape in your 3D modelling tool and still get a nice transition to the surrounding terrain. To do that well I guess you need to be aware of the terrain shape in your modelling tool. I would be happy to hear any feedback from developers that try this new approach on how that works and which improvements could be made there.

A while ago I changed the way the lighting works in the ModelConverterX preview. Before the light would always come from the view point, while now there is a separate light location. The downside of this change is that you now can see that some sides of the model are always darker.

I have been thinking about adding a nice time of day simulation where the sun moves around your object, but in the end I decided that is probably not so useful. Instead I have now added two sliders where you can manually alter the direction where the light comes from. The azimuth slider controls the direction it comes from and the elevation slider determines the height of the light compared to ground level.

You need to click on the button with the three yellow arrows you show or hide the toolbar where the sliders are location.

I hope this feature makes it even easier to inspect your model in the right conditions.

Another small change to the ModelConverterX preview. There is now an option to show a ground polygon as well. Especially when viewing buildings this might give a better impression of how the building will look. The color of the ground polygon can be adjusted in the options.

And the last (small) change for today. When viewing the grid the positive X, Y and Z axes are now coloured differently. This will make it easier to see what the orientation of the model is.

From the next development release scenProc will read the autogen configuration files from a different location. Until now these were read from the XML files in the Autogen SDK folder. But these might not always reflect the configuration that is actually loaded into FSX. So from the next version the tool will read the autogen configuration from the autogen folder of FSX. This ensures that the items you use in scenProc are also available when you start FSX.

Because the autogen configuration can be stored both as XML and as SPB file in the autogen folder, scenProc can now read from both of these formats.

One word of caution, in your FSX autogen configuration there could be elements installed by other addons. Be careful not to use these in your own addon, as you can’t expect your users to have the same addons installed as you do.

I have just made an update for DrawCallMonitor. With this update you can also load an object library BGL file and see the statistics of each object. The be able to switch between objects there is a list displayed on the right.

This update should make it easier to inspect files to see how many drawcalls they have, if they have drawcall batching enabled, etc.

Some might wonder why not use ModelConverterX for this, since it can also show this information. The difference between the two tools is that DrawCallMonitor will show the statistics as they are in the MDL or BGL file. While ModelConverterX will load the object and then derive the statistics from its internal representation of the object. In most cases that gives the same values, but not always.

I have made a few small changes to the ModelConverterX settings when it comes to drawcall batching. With these changes it is now also possible to make MDL files without drawcall batching. In some cases that is needed, because the batching can give some artifacts.

Before there was one setting that controlled whether LOD worked or not. That setting was called DrawcallBatching. Now there are two settings:

DrawcallBathching, this determines if objects are exported for drawcall batching or not

DrawcallBatchingWorkingLOD, when DrawcallBatching is true, this determines if LODs are working or not.

Let me start by saying that the recent scenProc releases might be a little less robust. Some users are reporting crashes since I made the change to read the FSX autogen configuration from the FSX installation folder, instead of the SDK.

To help me to figure out what goes wrong, because as a developer would always say it works fine on my PC, I have added an error reporting function to scenProc. It works just like the error reporting in ModelConverterX. If you encounter a crash, you can send a report to me and it gets logged in my bugtracker automatically.

So please do so if you encounter a crash, as it helps me to make the tool more robust and fix issues I might not even be aware of now.

Last month at the FSKonferenz in Paderborn I gave a presentation titled “Using GIS data to create FSX autogen”. I have now made a recording of this presentation and put it on YouTube so that those who where not at the conference can also see it.

The presentation covers how autogen works, what GIS data is and how you can use scenProc to create autogen from GIS data.

In my bugtracking system I now and then get error reports from people who run out of memory while working on a model with ModelConverterX. These bugs are often impossible to reproduce on my side, as it depends on the PC the application is run on.

If you are using the 32 bit version of ModelConverterX, have a PC with not too much memory and working on a quite complex model with a lot of textures, you might run out of memory.

To help those users I have added a new option now. With this option you can disable the preview. You can find it under the rendering options. This means that the object is not shown in the preview. As a result of that the textures are not loaded either (if you don’t open the material editor). This can save quite some memory and hopefully that is enough to finish the work you were doing on the model. All the editors and export function will still works as usual.

A little while ago I changed how the autogen configuration is read into scenProc. This change resulted in some unexpected crashes for some users. These seemed to happen mainly when FSX was installed within the Program Files folder and Windows did not give the right permission to read the files.

I have now made the code to read the configuration more robust and also worked around these permission issues. So if you download the current version these issues should be fixed. So if you downloaded scenProc in the last week or two, please update to the latest version to save yourself some trouble.

A while ago I started to explore the possibilities of custom autogen objects a bit more. I wanted to see what I could do with custom vegetation groups for polygonal vegetation. In this post I want to share some of my finding until now.

Using the Annotator configuration editor it is not so hard to add new objects to the AutogenDescriptions.xml file. Instead of adding a tree model, I decided to add some models of cows and see how well that works as “vegetation” in a field.

One obvious benefit of this approach is that it allows the cows to be seasonal. I can setup the autogen so that the model does not show during the winter. With normal placement of the models in FSX that is much harder to achieve.

But I ran into a couple of problems when I used my new vegetation group in my autogen.

First my objects did not show at all. After some trial and error I found out that for autogen you can only use MDL files that have drawcall batching enabled. If that is not the case, nothing will show at all. So if you made your model in GMax it will not work, you first need to change the MDL to use drawcall batching (you can do this in ModelConverterX).

The second problem is shown in the picture below.

You might wonder what it is, but I got all kind of weird effects on my screen. It looked like huge polygons with random textures from the surrounding. After some more trial and error I found at that if I reduced the complexity of my cow model these effects are gone.

I think it is related with too many polygons in a single drawcall, but I can’t be sure of course. From my experimentation I have concluded that it is best to keep autogen models below 200 triangles, then these issues don’t seem to happy with the maximum autogen density. If the vegetation class is less dense (by adding a zero guid with enough weight) the higher triangle count models work fine as well.

So now I have some cows standing around in my field and they are placed with autogen. I quite like the effect and will continue to explore other ways to make more use of autogen.

This must one of the most annoying “features” of the FS SDK tools. Many of them only work correctly when the decimal character is set to a dot. For example MakeMDL or XtoMDL refuse to work correctly when the decimal character is a comma. Many developers bump into this problem, since a lot of countries have the comma by default. I found this nice map on Wikipedia to show which country uses which decimal character.

But it would be too easy to only complain that Microsoft made their SDK tools in the wrong way. When developing my own tools I also often encounter this problem. Especially when working with file formats like SCASM or X files, that should always use a dot. When parsing or writing such files it is very easy to forget to add the instructions that make the code always use the dot.

My aim is to let me tools work well with both settings. But I have my own PC set to use the dot, due to the SDK tools that only work in that case. So therefore I tend to do less testing with the comma. So tonight I made some changes again and now the ground polygon wizard should work fine with both settings. Only when the SDK tools are needed, like when exporting MDL files, the user will have to change his settings. But in all other cases I try to let my tools work fine whether you use a comma or a dot.

But it remains an annoying issue, wouldn’t it be much easier if the entire world used the same symbol as decimal character?

In the attached object editor of ModelConverterX you can add lights to your object. On export to FSX these lights will be converted into effect (FX) files. Besides the colour you can now also specify a blink duration for those lights. This means you can create flashing lights.

If you enter a blink duration of 0 seconds you get a static light as before. If you enter 1 second you will get a light that is on for 0.5 seconds and then off for 0.5 seconds. If you enter 3 seconds for the blink duration you will get a light that is on 1.5 seconds and then off 1.5 seconds. I guess you’ll get the pattern. The smaller the number, that faster is blinks.

I was looking for a way to help me develop the scenProc tool and explore the possibilities of autogen further. In the end I decided to start a little scenery project where I could play around with all aspects of autogen.

I decided to pick an area in the US, because there is a lot of data available from the USGS. That makes it easier to do a photo scenery. An island is always a nice location for a test area, because you have a natural border of the area you are working on, I decided to use the Nantucket island in Massachusetts. The state of Massachusetts also has a nice website of their GIS service where you can find a lot of data.

So I got 30 cm imagery of the island and processed that into a photo scenery. I will make another post about the techniques I used for this soon. Below are some pictures of the photo scenery in FSX.

So now I can start the challenge to populate the island with autogen. I’ll start with the vegetation and the buildings. And after that I’ll see what other autogen elements I can still add. Hopefully I can use the autogen to represent the atmosphere of the real island, as shown on the picture below.

By the way, I don’t know at this moment if this scenery will be an addon that I will publish later on or not. For me it is really a test area to help me develop the tools further. And making it ready for a release does not have priority for me. And the island also has an airport, so maybe I can test some new ground polygon wizard ideas there as well later on.

As I mentioned in my previous post I would write a bit more details about how I created the photo scenery for my Nantucket test project.

From the website of the Massachusetts GIS department I could download 30 cm imagery of the entire island. But they came in 101 tiles and in the SID format. So how to make them ready for a FSX photo scenery?

My normal approach would be to make a mosaic of the images into one big GeoTIFF and then it is quite easy to make a photo scenery with resample. But for the entire island at this resolution that would result in a file of around 20 GB. So that is not something that resample can handle.

So I took another approach here. First I used GDAL to convert all the SID files to GeoTIFF and I made sure they are reprojected to geodetic WGS84 as resample requires. I did this from the command prompt:

for %f in (*.sid) do gdalwarp -t_srs "+proj=latlong +datum=WGS84" %f %~nf.tif

So now I have a whole bunch of GeoTIFF files in the projection that resample can handle. But there are more than 100 hundred files. So that makes writing the INF file quite some work. To tackle that I made a simple BAT file that will scan all GeoTIFF files in a folder and create a INF file that contains them all. Here is the code of the batch file:

@setlocal EnableDelayedExpansion

@echo [Source]
@echo Type = MultiSource
@echo NumberOfSources = 101

@set icount=0

@for %%f in (..\geo\imagery\gtif_wgs84\*.tif) do @set /a ICOUNT+=1 & @echo [Source!icount!] & @echo Type = GeoTIFF & @echo SourceDir = "..\geo\imagery\gtif_wgs84" & @echo SourceFile = "%%~nf.tif" & @echo Layer = Imagery & @echo Variation = All & @echo NullValue = 0,0,0

@echo [Destination]
@echo DestDir = "..\..\scenery"
@echo DestBaseFileName = "Nantucket"
@echo DestFileType = BGL
@echo LOD = Auto
@echo SplitFileLOD = 10
@echo Compression = 85

As you can see there are still some paths and numbers hardcoded. If I would use this kind of script often, I would probably better make a tool for it. Maybe I can add the functionality to resample.

Then the last step was just to run the INF file through resample and wait a few hours. And there it is, a photo scenery made from a whole bunch of files that could easily be downloaded from the USGS.

Of course there is more to do. For example add a watermask to get the dynamic water. And add a blend mask to get a gradual transition at the edges. But those tasks I still have to do. Once I have done them I will write about my experiences again.

One of the first problems I encountered when I tried to make autogen for Nantucket is the lack of vector data for the vegetation. OpenStreetMap contains hardly any vegetation and also the GIS department of Massachusetts has not much usable data.

So therefore I started to experiment with detecting the vegetation in the imagery.  And while playing with this idea, a similar tool popped up at the FSDeveloper forum.

The approach I am testing now is to check the histogram of a small part of the imagery and based on the average value and the standard deviation decide what is forest and what not. I have made a small test tool to see which algorithm works best. Below you see a screenshot of the imagery and the detected vegetation.

Of course it is not yet perfect. As you can see some vegetation ends up in the water for example. I have already seen that different images sometimes need different settings to get the right result. I am thinking about turning my test tool into some kind of configure tool. Hopefully if as a user you click on some areas that are vegetation and some areas that are not, I can have the tool figure out the best filter for that type of imagery.

Once I find an algorithm that works OK, I plan to put this functionality in scenProc as well of course. But for now there is more testing and exploring to do.

Below is a quick screenshot of the result I got now in FSX. I think it is not too bad, but there are still some bugs left. And I might have to pick a different type of tree to match the Nantucket area better.

I am travelling for my work this week, but when I had an few hours in the evening to spend in my hotel room I did some more experimentation with the tree detection algorithm.

I have now modified my test tool so that you can click on the trees in the image to determine the rules that are used for the detection. Just click on a dozen different trees or so, and the tool will figure out which rule should be used to find the trees in this kind of image.

From the tests I have done it seems to work quite well. Below are two screenshots of the Nantucket imagery where I used to same rules to find the trees in both images. I am quite happy with the result till now.

Next step will be to add this algorithm to scenProc, so that I can test it on a bigger area and see if the results still look convincing. I am curious to see how this autogen will turn out. But that will have to wait till I am back home, I don’t have FSX here at the moment.

I have made some more progress on the tree detection algorithm in the last days, but I am not there yet. So some more testing is needed before the functionality can be put in scenProc.

In my previous post I showed some results from the algorithm running in a test application. What I have done now is put it in scenProc itself. This means that scenProc can now read raster files through GDAL, run the histogram based filtering on the image and create vectors from the results (thanks to GDAL and OGR again).

Here are my first findings of putting the algorithm in scenProc:

• It is still very slow. Running the whole island of Nantucket through the tree detection algorithm takes more than half a day. So I guess it would be a good moment to get the profiler tool again and find out where performance gains can be made.
• The screenshots I showed last time were from images at a lower resolution. I had down sided them from the 30 cm resolution to make testing easier. It seems the filter that worked well on those, does not necessary work well on the full resolution as well. It seems resizing them made the trees slightly darker. So I will have to do some more testing to see which filter settings work well with the full resolution.
• With the algorithm you get a lot of relatively small polygons. Most polygons cover a few trees. Only in a dense forest you would get bigger polygons. Creating polygonal autogen vegetation from these small polygons does not work well, quite often no trees show at all in FSX. Using rectangular autogen vegetation seems to work much better. Even for a small rectangle at least one tree will show up. So it seems rectangular vegetation would be the way to go with this algorithm.

And now back to some more testing…