It’s two years ago already that we figured out that Annotator does not display the orientation of autogen as FS does. There is a distortion in the angle of the objects. So since this was figured out scenProc applies a correction to the orientation to make sure everything aligns correctly with the world.

But what if you use the ImportAGN step to load autogen into scenProc? If you load the autogen as autogen objects scenProc just keeps them in memory (so that you can add new autogen objects) and saves them again if you use ExportAGN. So in that case the distortion correction is no problem, it will just be preserved.

But if you use the option in ImportAGN to create features from the autogen then you will have an issue. When creating features scenProc will convert the autogen from the autogen coordinates to geodetic coordinates again. Until now the correction for the autogen distortion was not included in those calculations, which would give an error. So I have now updated scenProc to correctly “uncorrect” the distortion correction.

If you are creating features from autogen not made with scenProc (so autogen that doesn’t have the correction), you can add the  NOINVERSEDISTORTION option to the ImportAGN step to not apply the “uncorrection”.

I last nights build I have deprecated some steps that were marked as to be depcated for a while already. This includes the ExportSHP step. Since alternative steps are available for a while already this should not really give problems anymore. The reason to deprecate them now is that I found out that ExportSHP is not working correctly with the attributes in all cases and I don’t want to spend more time on fixing that. 

Lately I have been working with XML extrusion bridges for scenery and while doing so I noticed some weird artifacts. Even though I out the end points under the ground, they sometimes still float above it. And I also noticed that two bridges don’t always connect even though you specify the same position and altitude for the connecting point.

So I decided to dive a little deeper and see if I can understand what is going on. And after examining a lot of bridges I have come to the conclusion that the scenery engine adds a weird elevation offset to all bridges. And this offset is equal to the average height of all points of the bridge. So the taller your bridge is, the more the bridge is raised and thus also the more your end points will float.

The good news is now that I understand the logic behind the offset it is easy to compensate for it, to make sure you get the bridge you expect. But I still don’t understand why it was implemented like this. I mean when you type an altitude in the XML file that’s what you expect to get, right?

Better ways to filter out features in scenProc that are overlapping with others or that are close together have been requested for a while already and I have now implemented a new step called FilterFeatures that adds these possibilities.

With this new step you can for example remove all point features of trees that are close to a round or remove buildings that have bounding boxes that are overlapping with other buildings. Please check the manual for the details and examples of how to use this new step.

Some of this filtering could be done before by using the AddAttributeIfInside step, for example to add an extra attribute when a feature was inside another feature and then filter them out based on this attribute. But the new step will make this kind of filtering a lot more efficient.

I have added find and replace functionality to the scenProc GUI now. That should help you to find a certain text in your configuration file and also to make replacements more quickly. You’ll find those new functionalities in an extra toolbar that is shown right below the normal toolbar.

In scenProc the code completion will help you to select the right GUIDs for your vegetation or buidlings. But if you are not sure what the name of the class is or if you want to add multiple guids for random placement, that’s not always the easiest way.

So I have now added a context menu to these GUID attributes and selecting it will give you a GUI like shown below where you can easily select the GUID you want from the list. Just check the checkbox and the GUID will be added to your script.

I have fixed the scenProc filter bug that I wrote about a few weeks ago. Objects without an attribute were sometimes included in the results for double or integer attribute types. That behaviour has been fixed now.

While fixing it one new issue appeared though. The filter validation now doesn’t throw an error anymore when you try to compare a string to an integer. But I didn’t want to hold back the bug fix until I have been able to fix this issue. So the validation is slightly less good for now.

Over the last year I have been putting most of my focus on new scenProc features, so ModelConverterX did receive less updates than usual. But now that the end of the year is approaching I do have some new features for ModelConverterX for you as well. Let’s say this is my Christmas gift to all ModelConverterX users. I have added support for a few more formats, you’ll find the details on the changes below. A big thanks to the Assimp project for this as well, as I found that library very useful.

COLLADA

The COLLADA format is not also supported for export. You can export model geometry and the basic material settings to the COLLADA format. Most of the sub textures, like bump maps, are also supported in the export. So this should make it easier to import models in other tools.

Import of the COLLADA format was already supported before, but I’m using the Assimp library for that now. So hopefully everything still works as you are used to. The advantage of this approach is that you should be able to import animations from COLLADA as well, but I didn’t find good test models of animated COLLADA files to test it thoroughly.

FBX

The AutoDesk FBX format is now supported for importing and exporting as well. The importing is done through the Assimp library again and it can import geometry, animations and most material settings. Exporting is done using the FBX ASCII format and it writes the geometry and basic material settings for the moment. I hope most tools support the ASCII version of FBX as well, although I noticed that Blender doesn’t.

3DS

For exporting to the 3DS format I am using the Assimp library now, this replaces the old 3DS exporter I made before. Hopefully this solves the bugs in hte old 3DS exporter. Sometimes objects were exported corrupt and could not be loaded into GMax. I hope by switching to Assimp that is fixed now.

Wavefront OBJ

Importing and exporting of Wavefront OBJ files is now also done through Assimp. These are not new features, but I moved it to the new library to cleanup my code a bit. It should work just as it did before.

I hope you like all these new features. If you encounter any issues or bugs, please let me know.

A few years ago when I started to experiment with vegetation detection from imagery in scenProc I was looking for a test area with good imagery. I ended up picking the island of Nantucket, since it is a nicely sized island and for the US there is a lot of free source data to work with.

Later I found out that Bill Womack was also working on a scenery of the island, so my test autogen moved from just an experiment to something that would become part of an actual scenery. And combined with the great custom autogen textures Bill made the result is really fantastic.

Now Bill has released this scenery, so if you are looking for a nice VFR destination or just want to enjoy the scenery and the custom autogen check it out.

The end of 2016 is fast approaching, so it’s the time of the year to look back a bit on the last year and look ahead a bit to 2017 as well. For scenProc the last year has been very exiting, with a lot of ideas I had in my head coming to life. But I should also say directly that as users you haven’t seen much from this yet, because most of the new features are currently in a kind of alpha phase and are being tested in a project I’m involved with. In 2017 I hope that these new features will also start to move to the development release. Although I do not have a clear release plan for that in mind yet. But let me use this blog post to shed a bit of light on the possible future of scenProc, by describing some of the things I’m working on.

XML bridges

Currently scenProc can place XML scenery objects and effects for you. But I have been experimenting with placing XML bridges as well. The idea is that you use line vector data to generate such bridges automatically. The current results are quite interesting already, as you can see in the screenshot below.

Terrain vectors

A second area that I have been working on is the generation of terrain vector scenery using shp2vec. Since scenProc can already process geographical vector data the step to shp2vec is not that big. And using the filtering functionality of scenProc you can then select which data should be used for the different terrain vector types. Below is a screenshot of a test area in Luxembourg that has been populated with terrain vectors using scenProc.

Photoreal scenery

The main feature of scenProc has always been to generate autogen, but wouldn’t it be nice if you could generate the photoreal scenery as well? I have been working on exporting photoreal scenery using resample. Based on vector data scenProc can generate the water and blend masks for me and I have implemented basic colour corrections. I hope to do more colour correction stuff, for example for seasons or night versions. The image below is an example of a photo scenery made by scenProc (and autogen detected by scenProc).

Big area processing

The last area I’m working on is improvements for processing big areas. With Nantucket I did detection of vegetation, but wouldn’t it be cool to also detect the buildings? And Nantucket is “only” 120 km² in size. So how to scale things up if you want to process an area of let’s say 1500 times that size? I’m working on new features to run multiple scenProc instances in parallel to process such big areas and ideally I hope to distribute it over multiple machines as well. And of course the feature detection itself needs some optimisation to make it scale better. Below is a screenshot of the batch runner tool I’m working on for this parallel processing.

So as you can see there are a lot of interesting ideas that I have started working on and that will hopefully become reality in 2017. But I can’t promise when or in exactly which form the different features will end up in the development release. At least it shows in which direction I’m thinking.

The latest ModelConverterX development release contains a new feature that you can also do a reverse earth curve correction. In the previous versions you could already correct your model for the FSX curved earth, but with this new feature you can also undo such a correction again.

Besides that the Coordinate Converter tool can now calculate either latitude, longitude or flat earth XYZ or geocentric XYZ from any of the different formats. So this will be useful if you need to convert between them while developing.

The video tutorial below explains these new features as well.

In the latest development release you will find a new wizard, the Scene Builder Wizard. With this feature you can build one scene (object) from a set of FS library objects and their placement. With this information ModelConverterX will generate a combined scene that contains all these objects at the right positions. This might be useful to improve performance (when applied on a small scale) or when you want to convert an entire airport to another format or so. Once you have made the new object you can export or edit it like normal.

The video tutorial below demonstrates this new feature.

I the last week one new simulator was released and another one was officially announced. In this blog post I want to discuss what the impact on my various tools will be.

The new simulator that was released is Flight Sim World from Dovetail. After installing the early access version I have come to the conclusion that the MDL and AGN formats are still the same as in FSX. So from that point of view I expect no big changes are needed in my tools to support this simulator as well. However at the moment it’s not clear yet if there will be an official SDK for this simulator. Given that the formats are the same as FSX, I guess we could use the Prepar3D 1.4 SDK, as people with only FSX Steam Edition also have to do. If an SDK is released later on I will check what needs to be done for the tools to support it.

The other new simulator that was announced is Prepar3D v4. The biggest change there is the move to 64 bit. I’m sure there will be an SDK, just as prior Prepar3D versions had. So once it is released I will make sure that my tools can detect and use that SDK as well. As far as I know now, the MDL and AGN file formats have no big changes compared to Prepar3D v3, so I don’t expect big changes are needed to the tools. But once it has been formally released I’ll double check that again.

One note, for both simulators I need to check if the Autogen Configuration Merger tool works well on it. I haven’t checked if the autogen configuration file have changed in FSW and if it has a exe.xml to run a tool on startup like FSX had. That’s something I still need to look into. For Prepar3D v4 I will also need to make sure it’s supported by ACM.

I have just released a new build of my tools that supports Prepar3D v4 as well. Below it is listed what this means for the different tools.

ModelConverterX

As far as I know now the MDL and BGL format in Prepar3D v4 are the same as in Prepar3D v2, so there is no new file format you can export to. But ModelConverterX will automatically recognise the Prepar3D v4 SDK when installed. Also the Convert and Place Object Wizard has been extended to support Prepar3D v4 as output simulator.

scenProc

The autogen configuration files from Prepar3D v4 can be read and you can thus select this version of the simulator as the active version. Besides that the Prepar3D SDK will be recognised when searching for certain tools.

FXEditor

Prepar3D v4 is added as supported version, which means you can select it as the active simulator version so that the effect files will be read from that effects folder.

For the Autogen Configuration Merger tool I have posted a beta release to the forum today as well. Once that has been tested better I will officially release it.

All other tools didn’t seem to require changes at this moment, but if you have issue using them with Prepar3D v4 please let me know.

In my previous post about Prepar3D v4 support of my tools I mentioned that the MDL format didn’t seem to contain many changes. On further investigation it turned out that there are a number of changes and new sections in the MDL format. These are related to the following new functionalities:

• Support for a second set of UV coordinates, including the material attributes to specify which texture uses which set.
• New material attributes, mainly for the detail map and heatmap.
• Support for material scripts.

The development release has been updated to be able to write all these new features as well. In the material editor you will find a Prepar3D v4 specific section with all attributes that are only for Prepar3D v4.

Given these changes, you will find the Prepar3D v4 MDL and Prepar3D v4 BGL as a specific export format in the save dialogue now. In the options you will also have to set the path to the Prepar3D v4 XtoMdl and Bglcomp. If your SDK is installed correctly these tools should be detected automatically by the way.

This evening I have been testing Prepar3D v4 a bit more and I have especially looked at using visibility conditions in scenery MDL files. Before these were not supported at all for MDL files placed through BGL. We had to use SimObject for them, as tools like SODE do.

But with Prepar3D v4 things have changed a bit here, and I have been testing what that could mean. So what I did is add a simple visibility condition to part of an object. This the test code I used:

<PartInfo>
  <Name>vis_december</Name>
  <Visibility>
    <Parameter>
      <Code>
      (E:ZULU MONTH OF YEAR, number) 12 == if{ 1 } els{ 0 }
      </Code>
    </Parameter>
  </Visibility>
</PartInfo>

It is just a simple condition to show the scenegraph node only when it is the 12th month of the year. And the good news is that these kind of conditions now work. So you can have part of your MDL only show at a certain time of the year. This can be very useful if you want to show snow only in the winter or so. As a proof here are two picture, one taken in September and the other in December.

At the moment I could only use the variables from the environment section, which would limit the kind of visibility conditions only to time related settings (day, month, year, etc). I tried to test with some other variables, but didn’t have success with that yet. So it might be that interesting variables like the weather are still not support for scenery (or I just did something wrong).

Last week I made two changes to the hierarchy editor:

• You can now drag nodes in the hierarchy editor, so that you can give them another parent node. This can be used to animate attachpoints.
• You can specify a NoCrash option per modelpart now, this way certain parts can be excluded from the crash box generation.

Below are two video tutorials of the new features.

This week I was approached by an AeroFly FS 2 user with the question if scenProc could be used to make cultivation (the AeroFly name for autogen) for AeroFly FS 2 as well. Of course this was not the highest priority item on the wishlist to work on, but I liked the challenge and the data structure to write to seemed simple enough. So I sidetracked a bit from what I was actually working on and decided to give it a go.

The fact that I’m writing about it now already indicates that it worked. In the next development release of scenProc you will find support to create cultivation for AeroFly FS 2 as well. You can create plants (trees), buildings and lights.

Section 5.9 of the updated manual shows an example script that can be used for AeroFly FS 2. Using OpenStreetMap data I have scattered trees into forest polygons, placed lights along a road and create houses from buildings that are almost rectangular. Hopefully this sample script should be enough to get you going. If there are any questions or suggestions, just let me know.

Until today you could view the recent changes in my tools here on the website, there used to be a link for that in the menu on the left (or on the bottom if you are viewing on a mobile device). But lately that change log was not being updated correctly anymore, so that recent developments were often not visible. So I have decided to remove it now.

But that doesn’t mean I won’t make the recent changes visible anymore. From now on you will find a file named changeLog.html within the development release downloads. In this file you can see the 100 most recent changes in the software. So that should help you to see what has been changed. You can also find this change log here online.

ModelConverterX can read and write the mouse rectangles of virtual cockpit MDL files for quite a while already. But this week I fixed some annoying bug in that code. These bugs must have been there for quite a long time already. Now and then some issues with mouse rectangles were reported on the forum, but it was always hard to reproduce them since they typically show up in complex virtual cockpit models that are hard to debug. But with some good tips for forum users I was able to reproduce the problem in a simple object this week and that made solving the bugs a lot easier. So if you grab the latest development release now, you will not have problems with mouse rectangles suddenly getting other tooltips or that kind of bugs. This should make it more safe to edit virtual cockpit files with ModelConverterX.

What kind of bugs did I fix? First there was an issue that the mouse rectangle definitions were not always found correctly in the modeldef.xml file, so unnecessary extra definitions were made for that. This was caused by a bug in the implementation of the Copy tag in the modeldef.xml file.

Secondly the tooltips got mixed up on export sometimes. This was only the case for the custom mouse rectangle definitions that ModelConverterX made, so with the first bug solved this is less common already. But I found out that I wrote some elements wrong to the XML file, so that is also fixed now.

Just let me know if you find any more issues, as I’m not an aircraft development by origin, I’m less familiar with these aspects of MDL files.