ImportOGR and automatic projection detection

I have now modified the ImportOGR step of scenProc. For the projection you can now specify a value of AUTODETECT to tell scenProc to try to detect the projection used by itself. This works for most vector data formats that GDAL/OGR supports, as long as the projection data is specified correctly in the vector data. For example for shapefiles there is often a PRJ file that specifies the projection of the data.

If the automatic detection fails you can still specify it manually like it was done before. And the NOREPROJ value to specify the projection is already WGS84 geodetic coordinates is also still supported of course.

ImportGDAL and projections

Until now the scenProc ImportGDAL step required that the imagery you are reading was in WGS84 projection already. I have now changed this and other projections are also supported. If the imagery is not in WGS84 it will be reprojected by scenProc internally. This should make it even easier to run the feature detection feature on the imagery you have, as many sources don’t provide the imagery in WGS84 projection. So it should save quite some pre-processing of your data.

scenProc will try to automatically detect the projection that is used in your imagery. In most cases that works fine, if this doesn’t work out you can manually provide the projection as an additional argument to the ImportGDAL step.

There is one little catch, the internal reprojection is done in memory. So if you are already short on memory for your scenProc script, it might be better to still reproject your imagery manually. But from the tests I have done until now this shouldn’t be needed too often.

scenProc big area tips (2)

Here is another tip when using scenProc to process big areas. If you are working with raster data this can mean that you have to load a big amount of files. But there is an easier way. scenProc uses the GDAL library that supports reading GeoTIFF, JPEG2000 and other common formats. But it also supports WMS.

WMS stands for Web Mapping Service and is a technology to distribute imagery over the internet. It is this kind of technology that gives you the images you see in Google Earth for example.

To allow scenProc to read the imagery all you have to do is make a XML configuration file that specifies the WMS service. Below you will find an example and all details can be found in the GDAL documentation. Then you use this XML file as filename in the ImportGDAL step. Then the images from the WMS can be used in the steps that use raster features. Be aware that grabbing all the data might take a while.

<GDAL_WMS>
 <Service name="WMS">
 <Version>1.1.1</Version>
 <ServerUrl>http://gis.apfo.usda.gov/arcgis/services/NAIP/Florida_2013_1m/ImageServer/WMSServer?service=WMS</ServerUrl>
 <Layers>0</Layers>
 <SRS>EPSG:4326</SRS>
 <ImageFormat>image/jpeg</ImageFormat>
 <Transparent>FALSE</Transparent>
 <BBoxOrder>xyXY</BBoxOrder>
 </Service>
 <DataWindow>
 <UpperLeftX>-87.71</UpperLeftX>
 <UpperLeftY>31.09</UpperLeftY>
 <LowerRightX>-79.96</LowerRightX>
 <LowerRightY>24.42</LowerRightY>
 <SizeX>855776</SizeX>
 <SizeY>826421</SizeY>
 </DataWindow>
 <BandsCount>3</BandsCount>
</GDAL_WMS>

scenProc big area tips (1)

When you are trying to process a big area in scenProc getting all vector data loaded can be hard. Either you will have some big shape files that take long to load or you need to do some pre-processing to slice up the data before. But did you know there is an easier way?

scenProc uses the OGR library to read the vector data. This library does not only support many formats, like shape files or GML, but it can also connect to geographical databases. So if you put all your geo data in such a database scenProc can read from it using the ImportOGR step. And only the data for the bounding coordinates that you specified will be read. Instead of a file name you need to specify a database connection string like this:

PG:"dbname='databasename' host='addr' port='5432' user='x' password='y'"

Of course initially you need to setup the database and put your data in it. The connection string above is for a PostgreSQL database with the PostGIS extension installed. There is an easy installer  to get all this installed quickly. And with ogr2ogr it’s also not so hard to put your data into the database.

So the next time you start a project where you will use scenProc to process a big areas consider setting up a geo database first to make your life a bit easier.

Aircraft.cfg editor

In the next development release ModelConverterX will contain a new aircraft.cfg editor as well. This is an enhanced text editor that is linked to the 3D preview. This should make it easier to modify lights, contact points or exits for example. Because while you type the coordinates of the points they are updated directly in the 3D preview. The video tutorial below illustrates how the new editor works.

Reading aircraft.cfg files

I have added a new feature to ModelConverterX, besides the MDL format, you can now also read the aircraft.cfg file. Each of the models defined in the CFG file will then be read into the tool. And the liveries are based on the settings in the CFG file. This will give more accurate liveries than before in MCX.

When reading a MDL file directly, ModelConverterX will try to see if there is a matching aircraft.cfg file to read the liveries from as well. If that’s not found, no liveries can be chosen.

Besides the liveries you can also visualise the different points that can be defined in the aircraft.cfg file, like lights, exits or contact points. This should be helpful to see if they are at the right location compared to the model. You can’t edit these points in ModelConverterX.

The video tutorial below shows the new feature in action. I hope this is a useful addition for those that do a lot of work with aircraft models.

Anti-piracy measures reverted

Sometimes you have to try something to see if it works. A few days ago I introduced some extra checks that restricted exporting from ModelConverterX when you are modifying a model for which you don’t seem to be the author. I have now reverted those changes, because they didn’t work out as expected. There are three main reasons why they didn’t work as theoretically assumed:

  • The mechanism to detect if you are the author was not robust enough, it also gave this warning for people who were modifying their own models.
  • The mechanism didn’t account for the fact that some people want to make modifications for their own usage, without the intention to redistribute them.
  • The mechanism was mainly intended to protect the complex 3rd party aircraft models, but it turned out more and more AI models also use custom animations. It was never the intention to limit the modification of such models as well.

So due to these reasons I have removed the restriction again now and you can use ModelConverterX on any model as before.

Of course it is still very important that developers respect each others copyright. So that is something that I will keep stressing on the forums. But it didn’t turn out to be feasible to let ModelConverterX check this, without restricting many genuine users. What remains is an appeal on all developers to only distribute work that you have made yourself or for which you have permission to distribute it from the original author.

Oops, I broke it (again)

With the last development release of ModelConverterX, I by accident broke some functionality again. FS2004 BGL files gave an error on import. Of course I have fixed this bug quickly again, but still it’s annoying that this sometimes happens.

Why does this happen now and then? Basically because it’s almost impossible for me to test every feature when I make a change. But I’m trying to change this now. Lately I have been trying to work with unit tests more in my code. Unit tests typically test if certain functions work correctly.

But using the same test framework I am now also adding some integration tests to my test suite. This means that the test suite will try to load different kinds of objects (BGL files, DAE, MDL files, etc) and afterwards I’ll check if there were no errors and if the amount of modelparts or triangles is as expected.

This might not catch every possible error, but it should help me to detect quicker when certain files don’t load anymore. It would for sure prevent the bug that happened now where all FS2004 BGL files throw an error.

So I’ll go ahead and add more files to my test suite and hopefully that will reduce how often something breaks in the future.

Anti-piracy measures

A topic that is now and then discussed is whether ModelConverterX makes it too easy to steal the work of others. The capabilities of the tool indeed make this possible, but there are also many genuine uses of the tool that many developers use. It should probably been seen analogue to a hammer, which can be used to build a house, but also to break into one.

A small anecdote to underline this is that I have been approach by developers in the past who complained that they expected ModelConverterX was used to steal their work. But a little while later the same developer contacted me with a feature request, since he also used ModelConverterX in his own production chain.

Until now the approach in ModelConverterX has been mainly to warn users and make them aware that they need to consider copyrights. For example by showing a warning when you export a model. Also on the FSDeveloper forum this is a topic we often stress when making modifications of work is discussed.

But now that the skin and bone animations are supported, I hope to release this new feature in a few days, I have come to the point that ModelConverterX can import and export even the most complex FSX models without features being lost on export. The fact that complex features like animations, mouse rectangles, etc. were not supported before was in a few a “feature” to make piracy less attractive because certain features that require a lot of work were lost.

So therefore, together with the release of skin and bone animations, I will introduce some measures in ModelConverterX that will restrict non-genuine use of the tool. As seen in the picture below, when the tool detects that you are not the author of the model it will inhabit export and show a warning. How to detect someone is the author is not easy of course, but the approach that ModelConverterX takes is that it assumes that you are the author if all custom animations and visibility tags are in your ModelDef.xml file. If you don’t have all entries, it is assumed the model is not your work.

Image2015-10-21 1113.16.834

I hope that the ani-piracy measures as described above are a good balance between allowing genuine developers to use ModelConverterX in their workflow and making it not too easy for people with bad intentions to steal your hard work. If you have other suggestions or ideas on this balance, please share them with me or the community.