Effects with an offset

A topic that has been raised frequently on the FSDeveloper forums recently is that effects attached to an object in FSX have an offset in their placement. Especially when you use these effects for your taxiway lighting or approach lights that is an annoying “feature”.

So tonight I did a little experiment to see if I could reproduce these complaints. I placed three objects at 250 meter distance, each with an effect at the top. The last one was 500 meters from the reference point and as you can see the effect is not at the top of the object, but has an offset. At 500 meters from the reference point this offset was about 0.7 meter already.

Next I compared this offset with the difference you get when using the curved earth or the flat earth coordinates. And that difference was exactly 0.7 meters as well. So it seems the attached effects get corrected for the curved earth, while the geometry does not. That’s what gives the offset.

So know that the cause is known, it should not be too hard to fix this. I think I will add an option to ModelConverterX to correct the position of attached objects. But if you have a better idea how to fit this correction in your modelling workflow let me know.

Oops a mistake, undo please!

It’s probably on of the key combinations most used in computer programs, Ctrl-Z, to undo your last action. Until now ModelConverterX did not have any undo functionality. When I started with the tool an undo function was not really needed, since it was an object converter. You loaded an object and exported it into another format. If something went wrong you could just load the same object again.

But over time more functionality has been added to ModelConverterX and now it is not uncommon to perform a number of actions on the object before exporting it again. For example change some material attributes, add an LOD or reduce the amount of drawcalls. With all of these actions it can happen that you make a mistake of course. So I have now added an undo function to ModelConverterX as well.

The undo function works as in most programs. It allows you to undo the last changes you made. Either by pressing the undo button at the toolbar or with the common Ctrl-Z shortcut. ModelConverterX has no limit to the amount of undo’s you can perform at the moment, although the amount of available memory will put some constraint on it. In the options you can disable the undo functionality at all if you are running out of memory. Please let me know if limiting the amount of undo’s is necessary, but from my test I expect that the memory usage is OK.

Besides undo, there is also a redo function, which will undo your last undo. This works with the common shortcut Ctrl-Y or the button at the toolbar. In ModelConverterX the keyboard shortcuts Ctrl-Z and Ctrl-X were used before to select the previous and next object. Since that conflicts with the undo key, I have changed those two to Ctrl-X and Ctrl-C now.

Performance indicator render mode

I have added a new experimental render mode to ModelConverterX. This mode gives the object a colour based on the amount of texture vertices at a certain location. So this mode should help you to see where your object can be optimized further to increase performance. I have made a quick video to demonstrate it, since this is tricky to explain in words:

When analyzing the result keep in mind that this is calculated per modelpart. So where two different parts, with different material, meet, you will not see a higher texture vertex count. That is by design. As I already mentioned in the video, this is an experimental mode. I hope it helps to understand performance better, but please let me know if you have suggestions on how to make it more useful.

The return of DrawCallMonitor!

In my previous post I already mentioned that the object statistics shown in the DrawCallMonitor tool and in the Object Information form of ModelConverterX differ. I have done some more studying on this and it is hard to say which one is better.

DrawCallMonitor gives the right statistics if you want to know how many triangles, drawcalls and texture vertices a specific MDL file has. ModelConverterX on the other hand gives a good indication of how many drawcalls, triangles and texture vertices you will get when you export the object from that tool. There can be quite a difference between the two tools. I think this is due to different strategies, ModelConverterX tries to export objects with as little texture vertices as possible. Many of the default MDL files can be optimized to use less texture vertices, but I think at the moment they are build so that the triangles can be drawn with continuous triangle strips. It would be an interesting topic to compare those two approach performance wise. But that is a subject for later.

Anyway, having said the above, it is clear that a tool like DrawCallMonitor is still very useful when trying to examine MDL files. So I have decided to put the tool in the ModelConverterX development release. From tomorrow that release always contains the latest versions of ModelConverterX, FXEditor and DrawCallMonitor. The version of DrawCallMonitor is almost the same as the one released on the forum before. I have only made a few small user interface improvements. But now you are sure to have the latest version in a convenient place. So welcome back this tool to your tool suite.

DrawCallMonitor vs ModelConverterX

DrawCallMonitor is a tool I made some time ago to show statics about the amount of drawcalls, texture vertices and triangles used in a specific MDL file. Recently I have not updated this tool, because the Object Information form of ModelConverterX gives the same information. But is this information really the same?

While discussing how to minimize texture vertices with Lefteris recently we found out that the information shown by the two tools is not the same. So the obvious question then is which one can I believe more?

Given the way the tools are implemented I would say DrawCallMonitor is more accurate. It actually scans the MDL file and reports the amount of drawcalls, triangles and texture vertices mentioned in the part header. ModelConverterX on the other hand imports the object and stores it in an internal memory representations. From this representation it then calculates how many triangles and texture vertices there are. But sometimes things are optimized a bit already when importing. So it is likely that ModelConverterX might report less texture vertices.

I am currently comparing the code and how the tools work on different objects. While doing so I even found out that after exporting an object from ModelConverterX the amount of texture vertices was even lower than reported in the tool before. So I think it would be a good idea to figure out which figure is most reliable. You expect some more information soon!

ModelConverterX user settings

How ModelConverterX stores your settings is a topic that has resulted in some discussion on the forum already. So let me try to make things more clear with this post.

I am using a build in functionality of .NET to store the settings, which are conveniently called settings as well. This functionality automatically makes sure that the settings are stored on your computer and it does that per user on your system. So they end up somewhere in the application data for your user.

As long as that all works as expected that is fine of course. But when making updated versions things get a bit tricky. The settings functionality takes two things into account when determining where to store the data:

  1. Version of the application
  2. Folder name of the executable

The version of the application is something I don’t change often, only with major release. So the development release is version 1.3 for quite a while already. But the folder where the application is stored is something I don’t control of course. Some users prefer to keep different versions side by side, which I can understand, but that results in the user settings not being shared by the different versions. Most likely each new version will always start from scratch with all default settings. So if that annoys you, I would suggest that you always store the latest development release in a folder with the same name.

Having said all this, you know how the current implementation works. And hopefully it helps you to be less annoyed by loosing the settings when you upgrade. But I must also add I understand this is not a perfect situation. So I will be looking at better ways to store the user settings in the future. When I do that I will also look at related issues, like for example the desire to have different profiles for FS2004 and FSX models. But that is something for the future.

Animation slider

I have made a small change to the ModelConverterX user interface. The control to manipulate an animation have moved to a new toolbar now. Since this toolbar takes some space, it is only shown when the object loaded has an animation. Else the entire toolbar is hidden. This new toolbar also has a slider that you can use to move the animation frame. From tomorrow this change is in the development release.

Changes to FSDeveloper forum structure

Today I will be making some changes to the forum structure. With time going on, how we make our addons has also changed slightly. For example when we started FSDeveloper more ASM tweaking was needed, but now that forum is not so active anymore. With these changes to the structure we want to make sure you can find what you are looking for quickly. Let me stress that we won’t remove anything, we might merge two categories or put a subforum in a different category.

I will post all the details once I am finished with the changes. For now this is just a warning that today you might notice that I am making these changes on FSDeveloper. So if you suddenly see a forum move, don’t worry, it’s me.