A while ago I already wrote about the dangers of tiny buildings in autogen. The problem with those tiny buildings is that they will prevent other autogen from showing correctly in Annotator as well. Since some users reported such trouble recently, I have decided to automatically filter out buildings that are smaller than 1 meter in length or width now. So scenProc will automatically drop such buildings from now on.
I would also like to remind everybody that it is best to exclude your buildings in the SPLITGRID step. Don’t let them be sliced into small pieces, but only sort them into the right cell. This should prevent many of the small buildings appearing in the first place.
When I released the first update for ModelConverterX that supports the new Prepar3D v2 MDL format, I had already found out two differences in the MDL format:
- The material definition has been extended with an additional attribute for the ZBias
- The indices of the triangles are now stored as int instead of short. This basically means that you can have more triangles in a modelpart, because with a short you can’t have an index higher than 65536.
But a few days ago I found out that there are more changed sections in the Prepar3D v2 MDL file. It turned out that the way the mouse rectangles are stored has also changed. So I have now updated ModelConverterX again to support this change as well. You can download the new version tomorrow.
I have tested with most of the models that come with Prepar3D v2 and I haven’t been able to spot other MDL files with unknown sections. But you never know what we will find in the future…
I have added a new step to scenProc, PLACEPOINTSINPOLYGON. With this step you can place points in polygons. This can be useful if you want to scatter objects in the polygon for example. As arguments the step takes the distance between the points and the amount of randomness you want to use. Below you see two pictures, one without randomness and one with 50% randomness on the position of the points.
Now you might remember that there already was a step called PLACEPOINTINPOLYGON (do you spot the tiny difference in the name?). This step creates one point at the center of a feature. To prevent confusion that step has been renamed to PLACEPOINTATCENTERPOLYGON now.
The new Prepar3D v2 was released a few days ago, so it was time for me to update my tools to be more aware of Prepar3D. For Prepar3D v1 it in general worked if you just set the FSX folders to the Prepar3D folders, but with version 2 there are more changes. Therefore Prepar3D v2 is now recognised as a completely seperate platform. For Prepar3D v1 you would still have to use the FSX “mode” of the tools.
The Prepar3D changes affect many of my tools. Below I list the main changes for each of them. All the changes will be available in the development release of tomorrow.
- Can show drawcall related information for Prepar3D v2 MDL/BGL files as well now.
- Prepar3D v2 added to the options as preferred version. When selected the tool will default to the effects folder of Prepar3D v2. To do so it needs to know where Prepar3D v2 is installed, so that has been added to the options as well. When no path has been set yet, the tool will try to load the correct path from the registry.
Library Creator XML
- Can create Prepar3D v2 library BGL files as well now. It uses the Prepar3D v2 BGLComp for that, so you need to have the Prepar3D v2 SDK installed.
- The correct path where you installed BGLComp should be recognised automatically based on the registry values.
- Can read and write the Prepar3D v2 MDL format. For writing the Prepar3D v2 XtoMDL and BGLComp tools are needed. The MDL format changes that I am aware of now are supported, but I haven’t tested with very complex models yet. So if you find unsupported elements let me know.
- Support for the new ZBias material attribute. In the material editor there already was a ZBias attribute, since FS2004 had one. For Prepar3D v2 this value is put in the correct material setting.
- The correct path where you installed BGLComp and XtoMDL should be recognised automatically based on the registry values.
- In the Convert and Place Object Wizard you can now select Prepar3D v2 as output version.
- When exporting to X file you can now select if you want a FS2004, FSX or Prepar3D v2 X file.
- scenProc has not yet been fully updated to support Prepar3D, but if you enter the Prepar3D v1 or Prepar3D v2 folder as the FSX path the auto completion of the different autogen classes will work. Better support will be added later.
Yesterday I gave a presentation about scenProc for the FSDevConf. If you were not able to watch the session live, you can still view it on YouTube, you will find the presentation here.
Compared to some other scenProc presentations I have recorded before, I spend more time on explaining how to examine the GIS data that you are using. I have noticed that many users have trouble to analyse the structure of their GIS data. But it is important to understand which attributes are used in your data, as else it will be hard to make the right filters in scenProc. So hopefully this extra explanation will help you to get through that phase.
During the Q&A session at the end I also spend some time discussing the vegetation detection feature that is still in development.
The schedule for the FSDevConf has been announced. So have a look and put the sessions in your agenda that you would like to attend!
As you can see I will also be giving a few presentations. You can expect sessions from me about the following topics:
- How to convert a SketchUp object to Flight Simulator with ModelConverterX
- How to make autogen scenery from GIS data with scenProc
- What is a drawcall? Explaining the importance of drawcalls for good performance.
- Scenery Design 101, an overview of the different types of scenery that exist. How can you recognise them and how can you create them?
Just a quick note to let you all know that the online FS Developer Conference (FSDevConf) that we are organising is approaching quickly now. It is actually scheduled for next weekend. So that means that the coming week I won’t have much time to update my tools, so the reported issues will have to wait a while. I first have to prepare my presentations for the conference and to finish he other preparations for the event.
It’s been a while since I was working on the autogen vegetation for Nantucket. It was actually before my summer holiday. Afterwards I thought I would quickly fix some of the reported bugs and then return to this interesting issue. But as always I got carried away by adding some new features to ModelConverterX and so it is only now that I had the time to look at the autogen vegetation detection again.
Before the summer I was working on vegetation detection based on the histogram properties of an area. This worked OK, but sometimes it is hard to distinguish water and vegetation. So this time I tried another approach for which I needed imagery with a near infrared band as well. For Nantucket I was able to get hold of such imagery through the state GIS portal. It seems this kind of imagery is available for more parts of the US for free and in the coming years it is likely to become even more easily available.
Above you see a picture of this imagery. The quality is actually less than the imagery I have used for the photo scenery. But since we want to use it to detect the vegetation it does not matter too much. The most interesting part is the near infrared channel that is included. Below you see a color infrared version of the same area shown before. As you can see the near infrared information lets certain features stand out more.
I found a common approach to detect vegetation, with is called Normalised Difference Vegetation Index (NDVI). This algorithm uses the red channel and the near infrared channel and calculates an index based on that. The higher the value, the more likely it is vegetation. So I have implemented this as an alternative approach compared to the histogram matching algorithm I used before. The first results look better, although it is sometimes still hard to distinguish between a shadow and vegetation for example. Below you see a picture with the detected trees.
I think both algorithms are OK for usage now. So I plan to finish up the GUI I have been working on that allows you to tune the algorithms for the imagery you want to process. And then I will add the vegetation detection feature to scenProc. And given the complexity of the algorithms I will also add some documentation to explain how they works and what the settings of the algorithms do.
For a long time 3D objects for Flight Simulator could only be developed with a couple of tools. For example FSDS or GMax with the right gamepack. But over the last few years there is a trend to use more and more tools. For example SketchUp is also popular now to make scenery objects. Recently we have also seen more interest in using Blender to design for FS on the FSDeveloper forum. That’s why we have added a special subforum for it now.
To get the objects out of Blender and into FS you can best use ModelConverterX. From Blender you export as a DirectX X file. This way you can even export animations. In ModelConverterX you can then load this X file, tweak the materials and animations as needed and then export again. The X file Blender makes does not have all the FS specific extensions, but ModelConverterX will add them for you.
I’ll try to post a little more details about using ModelConverterX and Blender in the near future.
The scenProc processing step to create XML objects had a last argument that when provided would add the NoAutogenSuppression tag to the create XML object. In the next development release the behaviour of this last argument has been changed a bit. From now on it matters what you enter. That’s because you can now specify any of the additional tags that BGLComp supports. If you want multiple just separate them by a semicolon. The possible values are: