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?

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.

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.

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.

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

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.

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.

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.

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.