SceneryDesign.org
I have just fixed some bugs in the scenProc detect feature step. With these fixes the holes in the detected features should now be processed correctly. Before the holes where not always represented correctly.
Be aware that processing holes in features does take more processing time. So you might see that detecting the features takes longer if you have processing of holes enabled.
When I updated my tools to be Prepar3D v2 compliant there was one tool that I forgot, RADItor. RADItor is a small tool that is mainly used by aircraft developers to edit the radius and bounding box values of a MDL file. Sometimes these values need to be tuned for the aircraft to display correctly in the aircraft selection window for example.
I have now made a new version of RADItor that can edit P3D v2 MDL files as well, besides FSX MDL files. You can get the new version from here.
After the recent move of the FSDeveloper site to another server some of the download links to my tools as reported here on the tools pages were broken. I have now fixed them all.
All of the files are now hosted on this website directly, so you browse all old stable releases in one place if you want.
Today I have finally deprecated most of the pre-OGR importers. So that means that IMPORTSHP, IMPORTOSM and IMPORTKML are no longer available in scenProc as steps. You have to use IMPORTOGR from now on to read those (and many more formats).
One of the main reasons to deprecate them is to get rid of the dependency on the Microsoft Access database driver, which was used by the shapefile library used by IMPORTSHP. This dependency gave a lot of crashes, since it seems not everybody read the manual to check what other dirvers need to be installed.
With the switch to OGR this problems should be less. However I am seeing some crashes now from people that are related to the OGR libraries as well. These seem to be caused by wrong .NET framework versions. Make sure you have .NET framework 2.0 and 3.5 installed when using scenProc.
One of the issues with creating autogen is that vegetation polygons might suppress buildings. When the vegetation overlaps the building the building will not be shown. This can be a bit annoying, since you would like the building to suppress the vegetation normally.
To work around this problem I have added a new step to scenProc. With this step you can subtract features from each other. So this allows you to subtract the buildings from the vegetation polygons. That way both of them will show up correctly in the autogen. As you can see on the picture the step also allows you to add a small buffer zone that removes vegetation that is near the building.
The syntax of the step is as shown below. The first argument is the filter to select the polygons you want to subtract from. In this case I’m selecting forest polygons. The second attribute is the filter to select the features that should be subtracted. In this case I select my buildings. The third argument is the scaling that should be applied to the features that are subtracted. So in this case I double their size to get a buffer area. The last argument is optional. If you provide MINAREAPOLY there the algorithm will subtract the minimum area polygon of the feature (the best fitting rectangle), instead of the feature itself. For buildings that is often what you want, since the autogen buildings are created from this minimum area polygon as well.
SUBTRACTFEATURES|type=forest|type=building|2.0|MINAREAPOLY
From now on you will find a PDF manual inside the scenProc downloads. At the moment not all sections of the manual are finished, but I will try to complete it as soon as possible.
With all the recent changes to scenProc and with some of the functions being quite complex, I think it is important to have an up to date manual with the tool. I will for example describe in detail how the feature detection works.
This PDF manual will replace the manual on the wiki. I generate it from LaTeX source code that I keep together with the scenProc source code. So I’ll try to directly update the manual when I make some changes. That way you should always find up to date information.
A few weeks ago I made two versions of scenProc available on the development releases page. One for 32 bit operating systems and one for 64 bit operating systems. Since both of these files are rather big, due to the inclusion of all the GDAL/OGR libraries, it means that downloading an updated version can take a while. Therefore I have now added a third version, called scenProc update. This version only includes my own files and not the external libraries. So once you have installed either the x86 or x64 version, you can use the update version to patch it to the latest development release every time.
The autogen SDK shows us how the texture sheet that is used for generic autogen buildings is structured. There are parts for houses, medium/large building and warehouses. See the images below that comes from the SDK.
But the SDK doesn’t tell us which type of building get’s which part of the texture sheet. On obvious parameter determining which part of the texture is used is the height of the building and that depends on the height distribution that you set for the autogen file. But the length and the width of the texture also influence which part of the texture is used.
So I set up a test with buildings of different sizes and I made a table of the resulting texture that was shown. I have used the same colours as shown in the SDK picture below. So houses are pink, small/medium buildings are green, large buildings are blue and warehouses are green.
Below is the resulting table for buildings with 1 or 2 floors. The numbers shown in the headers are the width and the height of the building in meters. As you can see the small buildings all get the house part of the texture sheet, but once the buildings get bigger the medium buildings part is used (of course only the first two floors of that sheet). And even bigger buildings get the warehouse part of the sheet.
Below a similar table is shown, but than for buildings with between 3 and 5 floors. As you can see it is quite similar to the previous table. The white part indicates buildings that do not show with this height. These buildings do show with only 1 or 2 two floors and therefore follow the table above.
Below you find the table for the highest two building categories, 6-8 and 9-12 floors. The table is almost the same as the one above, expect that the large buildings part is used instead of medium buildings.
The scenProc IMPORTGDAL step to import imagery data assumes that the imagery you use is georeferenced in some way. So for example as GeoTIFF or as BMP file with an accompanying world file. But that is not always the case of course. Some developers use unreferenced images and provide the needed coordinates in the INF file for resample.
Therefore I have now added a new step to scenProc that will read these INF files: IMPORTINF. This will go over the INF file and for each image defined in there add it as a feature to scenProc with the correct georeferencing. Afterwards you can use the image in the DETECTFEATURES step for example.
The scenProc feature to detect holes from imagery often returns polygons with holes, especially in area with dense forests and some clearings in the forest. When the ProcessHoles option is set to true the holes will be processed for the output of the detect feature step as well.
But I have to give a warning, for big and complex polygons the output is sometimes corrupt. I will try to fix that issue, but for now you can improve the output by first applying a split grid step to slice your imagery into chunks. When the detect features step is run on those chunks the output is better in general. See an example configuration file below:
IMPORTGDAL|..\geo\imagery\gtif_wgs84_4band\321778.tif # SPLITGRID|0.001 # DETECTFEATURES|FTYPE=RASTER|filter_ndvi_test.tfc|OBJ|FOREST # MERGEGRID # EXPORTSHP|OBJ=FOREST|trees_test
As you can see I used quite a small grid (even smaller than the autogen grid). In the end I use a merge grid step to combine all the cells again and export them as one shapefile. That shapefile I can then use in my further processing to autogen.
An added benefit of the SPLITGRID step is that the performance of the feature detection gets better. When I ran it on the image as a whole it took around 4000 seconds, but now with the small chunks it takes only 300 seconds. So for better performance using split grid is also a good advice.