Autogen from OSM (3)

Since my last blog post about the autogen I have mainly been working on adding autogen buildings as well. This went quite well, I can now add the generic autogen buidlings as well as the row houses from my tool. There are still some issue that some of the buildings don’t get the right shape, that’s because in the autogen you don’t use the total footprint. I need to derive a orientation and size from the footprint information. But once those few issues are out, I think I can make the tool available to others for testing as well. Let me know if you are interested.

In have made a video to demonstrate the workflow of making autogen from GIS vector data.

Autogen from OSM (2)

Tonight I was able to fix the remaining bugs in my tool to generate the autogen forests from the OpenStreetMap data. One of them was that I didn’t know that in the AGN file all polygons need to be closed (first vertex the same as the last vertex). Below are some screenshots of how it looks in the Annotator tool and in FSX now. The photo scenery I use is the NL2000 scenery of the Netherlands.

Now that the forests are working, I am going to move to the houses. Let’s see what I can do with the house footprints from the OpenStreetMap data…

Autogen from OSM

As I mentioned in my previous blog posts I am trying to create autogen from GIS vector data. For my first test case I am using the OpenStreetMap data of the Dutch island of Schiermonnikoog. Below you see a screenshot from the data, as well as a screenshot in the Annotator tool showing the autogen I have made.

It isn’t perfect yet, but I am quite happy already with the first results from tonight. Some of the forests are still missing, so there are still a few bugs left in my tool. But on the other hand quite a big part is already there.

Next step after the forests will be to try the footprint data of buildings that is also in OpenStreetMap, since that was my prime goal anyway. So see if I could fill whole areas with autogen buildings. I’ll keep you posted about the progress.

agn2txt

If you download the development release package of my tools, you will find a new tool in there from today. I called it agn2txt and it dumps the content of an autogen AGN file to a readable text file. It is a tool that I used which learning more about the autogen file format. I have included it, because I thought it might be useful for others as well.

I have plans to later also add a txt2agn tool that can do the reverse step, so that you can make minor changes to the autogen by editing the TXT file. But I haven’t come to that yet, as I first want to do some more experimentation with making autogen from GIS vector data.

Importing into GMax

Today I was trying to import an object into GMax again. As usual I used ModelConverterX to make a 3DS file and then imported that one. But, also as usual, that meant a lot of trouble with the textures. Especially since the 3DS format can only store short DOS filenames, it can be quite some trouble to get everything imported correct.

I had heard of scripts to import Wavefront OBJ files before, so I decided to look around a bit. In the end I found this script. Using it, it became a lot easier to import my objects I have to say. There were only two things I had to figure out first (and I’ll share them with you).

 

  • To run the script go to the Utilities tab of the command panel. Press the MAXScript button there. Then run the ms file you downloaded with run script. After that you can select Wavefront OBJ Importer from the Utilities dropdown box. This will give you the GUI to load OBJ files.
  • When the texture files are not found (which usually means they need to be in the same folder as the OBJ file), they are removed from the material on import. So make sure the textures are there, since else you get a material with only the colour.

 

But for the rest this is a much easier way to get your object into GMax than using the 3DS file. I should have found this out earlier.

Level of detail for FS2004 models

Tonight I have been improving how ModelConverterX reads levels of detail from FS2004 MDL files. The LOD values are now calculated more accurately. Since I spend quite some time figuring out some details I had figured out last year already (but forgot since then), let me sum up my main findings about levels of detail:

  • The LOD switching distance is determined by the object radius and the LOD value. For example a LOD value of 40 means that the object will switch when 2.5 times the radius of the object covers 40 pixels.
  • The LOD value of the highest LOD is not relevant, since this LOD is never tested. So when you have an object with LOD_010, LOD_040 and LOD_100, it will display the same as that object with LOD_010, LOD_040 and LOD_200. For ModelConverterX this means it can not accurately read the highest LOD value, since it is not stored in the MDL. ModelConverterX will assume it is twice the LOD value below it.
  • The radius of the object used for LOD calculations is a sphere fitting tightly around the object, so it is not the radius of the bounding box.

FSX AGN files

On the FSDeveloper Wiki we have a page describing the FSX autogen (AGN) file format. Today I have been experimenting with AGN files a bit, so I have added more information to this page. Polygonal buidlings, library objects and row houses are not also described. For the other sections I have added some extra explanation as well.

Why did I do this? I wanted to see if I can create AGN files based on shapefile footprints of buidlings. So understanding the AGN format was the first step in that process. I have now made a small tool that can decompile a AGN file into a text file. My next step will be to make a compiler to do the reverse step. The last step would then be to make a small tool to turn the shapefile information into such a text file for my compiler.

I am not sure if compiling and decompiling AGN files is useful to other developers. If you think it might be useful let me know.

Saving your library

One of the items I am changing in the new Library Creator XML 3.0 is how you save your library. Before you had to save the XML and compile the library to a BGL. Now those two actions are combined in one form that saves your library. You can choose if you want to save BGL, XML or both. Below you see the current version of this save library form. I am still tuning the user interface a bit, so in the released version there are probably some small changes.

The good news is that the first (beta) release of the new version is getting close, I have almost finished the features and only need to do some additional testing to make sure there are as little bugs as possible. The new version will be included in the development release packages, that also contains the latest ModelConverterX and FXEditor. The first version will have the improved user interface, the option to open your objects in ModelConverterX from Library Creator XML and the option to list all textures used in a library. The features to read BGL files directly or to add objects directly from ModelConverterX to a library will be added later.

Library Creator XML 3.0

I am working on an updated version of Library Creator XML. Not that there is much wrong with the current version, but I would like to add a few new features. And to be able to add them easier I decided that I would first cleanup and optimize the current code a bit. So that’s what I am doing at the moment. I will also give the tool a new user interface that is more in line with my recent tools. Below you see a first screenshot of this new user interface.

So what kind of features do I plan to add? Here are the ones that are at the top of my wishlist:

  • Export list of textures used by library
  • Open BGL library files in LibraryCreator XML
  • View an object from the library in ModelConverterX
  • Add objects to a library directly from ModelConverterX

Let me know if you have ideas for other interesting features. Not all of the feature above will be available in the next release by the way, I am going to add them gradually.