One feature often requested is the ability to export FS2004 aircraft MDL files as well. I have now set a first step in the direction of this functionality. If you download the development release tomorrow you will see that you can export both FS2004 scenery and aircraft MDL files.
But before you get too enthusiastic, let me warn you. The aircraft exporting is VERY limited at the moment. For example all animations will still export as tick18 (like they do in the FS2004 scenery MDL). And other more complex aircraft features are also not yet supported.
My first priority is to get the animations working. I think either I will let the user define the FS2004 style animation names in the animation editor (now FSX style names are used there). Or I’ll add some mapping between those two.
So why did I make this very basic exporter available already? Because I am looking for some users who want to help me test it. And based on your feedback and experiences it will be a lot easier to complete this function. So if you want to help test it, just post your feedback on the forum and together we can improve the tool further…
I think every designer exporting objects to FS2004 has seen the error message on the right at least once. It happens when you export a small object to a FS2004 MDL file with MakeMDL.
The reason is that somewhere inside MakeMDL, when calculating the octtree for the crash detection, some assertion is triggered. Of course this is nice to know, but it doesn’t help you as you still have that same error.
The standard fix for this in GMax is to add a fully transparent dummy box that is big enough. This will make sure that the object gets compiled by MakeMDL. And the polygons of the fully transparent box don’t end up in your MDL file, MakeMDL will filter them out for you since they are fully transparent.
Today I have updated the FS2004 MDL exporter of ModelConverterX. When you try to export an object that is small (small enough to trigger this error), it will automatically add a dummy box for you. So you don’t need to worry about it anymore. As a result you shouldn’t be bothered with this assertion message anymore in the future.
The next development release of ModelConverterX contains a number of changes related to object placement. The main change is that you can now place multiple instances of the same object from within ModelConverterX.
The placement is no longer done from the Object Information form, instead a new Object Placement form has been added. You still have the familiar reference map that can show maps from different providers.
Another big change is that there are two export buttons now. One to export objects and one to export scenery. Let me explain the differences.
Export object will export only the selected object to the format of your choice. You can choose any of the supported 3D object formats. No placement information is exported in this case.
Export scenery will export all loaded objects and their placement information at once. For the moment the supported formats are FSX BGL, FS2004 BGL and BGLComp XML.
I have made a video tutorial explaining the changes.
On the surface this might seem a relatively small change, but underwater I had to make quite some changes to make everything more flexible and support multiple placements. I have tried to test all features, but if you have trouble with the latest development release please let me know.
With the changes I have made now it will become quite easy to add support to scenProc to export XML object placement as well. So that is something I will be working on soon. And these changes also allow me to finish the ObPlacerX² object placement tool that I have been making a prototype of secretly :).
I have added a new processing step to scenProc that allows you to turn polygons into rectangles. This step is mainly useful when creating autogen vegetation for FS2004, since the vegetation must be rectangular there.
What the step does is just take the polygon and try to fill the shape with rectangles of the size specified. You can also specify the percentage of overlap you want between the rectangles. A random factor can also be specified to give the position a little more variation. Below is an example configuration file that shows how it works:
I have added a new function to ModelConverterX. It can now also read X files. This can be a X file generated by the FS2004 or FSX gamepack, but also a X file generated by another tool that does not contain the FS specific information. The following features will be read from the X file:
Geometry, normals and texture coordinates
Material settings (including FSX specific material settings)
This new functionality is in the latest development release. Let me know if you have any issues with this feature.
I have just put the first version of the Animation Tweaker in the ModelConverterX development release. You will find it in the Wizards menu. This first version can do two things (or actually it does those two automatically to all files you process with it):
Make FS2004 animations with more than 1024 frames
Update the animation to use local variables
As input to the wizard you should use FSX MDL files. I did test this new function with some test files here, but please let me know if you have issues with your files. It is a first beta, so might be a little buggy.
Remember the limitation in the FS2004 GMax for the length of animations? The tool does not allow us to export animations longer than 1024 frames. This is quite annoying, since that limits your animation length to only 55 seconds. Luckily the FSX gamepack does not have that limitation.
I have written down how to tweak the ASM code to get longer animations. But I’ll be honest, it’s quite complex code and you need to know quite a lot about how the animation code works to make the tweaks. So I can understand that it is not so appealing to many developers.
This morning I woke up with a good idea (why did I not try this before?). What would happen if I would make a long animation in the FSX gamepack and then convert it with ModelConverterX to a FS2004 MDL file? Guess what, the 1024 frames limitation is not completely in MakeMDL, a big part is in the gamepack DLE file. So that means that my new FS2004 MDL files contains all 33334 frames I put in the animation. The only problem I noticed is that the interpolation logic above is still written for 1024 frames. So that part still has to be tweaked. But at least you don’t loose any of the keyframes.
So I think I should add a tool to ModelConverterX that can automatically do the remaining tweaking. If all the keyframes are preserved, that is not so much work anymore in the first place.
It just puzzles me why I only think about this so many years after FSX has been released…
A first release of the new Library Creator XML 3.0 is now available, you can get it as part of the development releases of my tools. The main changes are in the user interface, I hope the tool is even easier to use. Another reason for the changes is that with the changes I made now it will be easier to add new features in the future. One feature high on my list is being able to import a library from BGL. So that will come in a future update. I made a quick video to illustrate the new version:
Tonight I have been improving how ModelConverterX reads levels of detail from FS2004 MDL files. The LOD values are now calculated more accurately. Since I spend quite some time figuring out some details I had figured out last year already (but forgot since then), let me sum up my main findings about levels of detail:
The LOD switching distance is determined by the object radius and the LOD value. For example a LOD value of 40 means that the object will switch when 2.5 times the radius of the object covers 40 pixels.
The LOD value of the highest LOD is not relevant, since this LOD is never tested. So when you have an object with LOD_010, LOD_040 and LOD_100, it will display the same as that object with LOD_010, LOD_040 and LOD_200. For ModelConverterX this means it can not accurately read the highest LOD value, since it is not stored in the MDL. ModelConverterX will assume it is twice the LOD value below it.
The radius of the object used for LOD calculations is a sphere fitting tightly around the object, so it is not the radius of the bounding box.
For a while I am thinking about how to integrate the different tools I have made better. An example of this integration would be to open objects from Library Creator XML directly into ModelConverterX or easily insert an object from ModelConverterX directly into a library. While playing with those integration idea I had another idea. ModelConverterX already has a simple object placement function, so why not extend it with a proper object placement tool? Like a FSX update of ObPlacer XML. Below is a quick video of a prototype tool I made for this.
My question is would yet another object placement tool be useful or not? We already have Instant Scenery and WhisPlacer. And a tool like ADE can also place objects at your airport already.
I am not planning to give my tool full live preview capabilities like Instant Scenery or WhisPlacer. Many because personally I never use that feature. As you can see in the video I have been experimenting with using background images like OpenStreetMap or Bing to show reference maps you can place the object on.
Let me know what your ideas are about such a tool and maybe in the future this tool can be added to the suite. But don’t hold your breath for it, this video is just a prototype and I have no fixed plans yet to make it a full tool.