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.

2473 days and counting…

Sometimes a feature is on the wishlist for quite a while. For example the feature request to support skin and bone animations is on the ModelConverterX wishlist for 2473 days already. But since the end of august I’m working on this feature request now and I’m making good progress.

I can already read the skin and bone animations from the MDL files and exporting them again also works. At the moment I’m trying to get the jetway IK animations to export correctly, which is not completely working yet.

Once that is done, there are some minor points that need to be addressed and then this feature will end up in the development release. Let’s see if I can make it before the request is on the wishlist for 2500 days…

Prepar3D v3 support

The development releases of my tools now support Prepar3D v3. In the rest of this post I will provide the details about what this means for the different tools.

ModelConverterX the Convert and Place Object Wizard supports P3D v3 now, so it’s a version you can select to export to. Also the P3D v3 SDK  is considered equivalent for the P3D v2 SDK, so when it comes to write MDL and BGL files I see the two versions the same for now. It seems the MDL format still has the same version. If differences are found in the future I might have to add P3D v3 MDL files as a separate output type. But for now either the v3 or v2 SDK is used to export P3D v2/3 MDL files.

scenProc you can provide the path to P3D v3 in the options and select it as a supported version in the combo box, this will ensure that the autogen configuration files are read from the P3D v3 folder. When it comes to exporting BGL files P3D v3 is considered equal to P3D v2 (see the details above for ModelConverterX).

FXEditor together with adding support for P3D v3 I have added a new options form. This allows you to specify the paths of the different FS versions. Using a combo box you can now easily switch between the versions you want to use. The active version determines where effect files are loaded from by default.

Library Creator XML when exporting P3D v2 libraries the P3D v3 SDK can also be used (see details above for ModelConverterX). No other changes made.

I don’t have P3D v3 installed myself yet, so I haven’t been able to test the support properly. If there are any issues, just let me know.

Hierarchy Viewer becomes Hierarchy Editor

The Hierarchy Viewer of ModelConverterX has been renamed to Hierarchy Editor now. As the new name suggests you can now also make changes in this editor.

I have added support to change the visibility condition and mouse rectangle of nodes now in this editor. If you click on the name of the currently assigned value, you will get a drop down box where you can select which visibility condition or mouse rectangle you want to use. The content of this drop down box is based on your ModelDef.xml file. If you select the top item named “None” from the list, then the node will have no visiblity condition or mouse rectangle assigned.

So this allows you to add, remove or change those items for each node of your model. Hopefully this is a useful addition and if there are other suggestions on how to improve the hierarchy editor just let me know.

Image2015-10-04 1214.27.954