I have updated to a different build server today. I won’t bother you with all the technical details, but this means that I use different software now to create the development releases of my tools automatically at night. For you as a user nothing changes, all download links stay they same. It’s only the build software in the background that I have updated. From my tests it seemed the migration went fine, but if you notice anything weird with the development release in the next day’s let me know.
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.
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.
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>
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.
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.
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.
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.
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.
The next development release of ModelConverterX will support skin and bone animations. I have made a little video tutorial to show all the new features and how you can use them.