iBlueYonder Nantucket released

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.

Support for more formats

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.

scenProc filter bug

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.

GUID selection context menu

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.

image2016-10-15-2200-33-990

Find and replace

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.

image2016-10-06-2037-15-316

Filtering features

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.

Understanding extrusion bridges

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?

Removed some steps

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. 

ImportAGN and autogen distortion

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”.

Improved validation

With the new filter syntax I introduced about a month ago, I did also see an increase in error reports due to issues with the filter syntax. Most of the time these errors where caused by user input (sorry to say this), for example because in the filter it was tested if a string is bigger than an integer or because the filter only listed a variable name but without a condition.

I have now improved the validation, so that these errors will also be reported while you type your script. To be able to do this I had to implement a “quick attribute scan” feature that will check your source data for the types of the attributes. Since this involves opening your geo data files I decided to schedule this check a bit less frequent than the normal validation, else the performance would probably be hurt too much. So it could take a few seconds before all errors related to the filter appear.

Hopefully these changes help you to write the correct filter syntax more easily. And hopefully it also reduces the amount of errors being reported.