Where do the bug reports go?

A few months ago I added the error reporting function to ModelConverterX. This means that if the program crashes, you can send in an error report. But you might be wondering what happens after you send it in.

At the moment 203 errors have been sent in and this is what happened with them:

  • 3 reports are still open and have to be investigated further
  • 45 of them have been fixed. In most cases this means the bug has been fixed. For some rare bugs it could also be that the crash has been prevented by adding an extra warning, but that the limitation is still there.
  • 57 of them I could not reproduce, this is usually the case when no object to test the bug has been included in the error report.
  • 2 of them were not fixable, these were shader errors due to limitations of the hardware used.
  • 83 of them were duplicate error reports, either because multiple people sent them in or because a user sent the error twice.
  • 10 of them required no chance, either because the problem had already been solved or because the problem was caused by something else.
  • 1 was suspended, which means it should be solved in the future, but has been delayed because it is a rare problem.
  • 2 of them I decided to not fix, this are bug that are very rare and should not happen again.

Combining all this I am very happy with the error reports I receive. They help me to understand better what kind of issues users encounter and thereby I can fix the bugs quicker.

So thanks everybody for submitting them and please continue to do so. And don’t forget to include the object that caused the crash, as that helps a lot to reproduce the problem.

scenProc GUI progress

I have made some progress on the scenProc user interface. The buttons to process the configuration file are working now, all processing steps report their progress and messages in the GUI, there is syntax highlighting and tool tips showing help about the processing steps.

Next item to work on is auto completion while editing the configuration file.

Bye bye command prompt interface

Today I have started working on the graphical user interface for scenProc. The idea is to make a kind of text editor that will help you to define the configuration file for scenProc. Below is a first screenshot of the new user interface.

Once I have the basics finished, I will turn my attention to feature like auto completion, syntax highlighting, dynamic error checking, etc.

MSTS support?

So, I was on business trip and had an hour to spare or so before we would go to dinner. What would you do with that bit of time?

Triggered by some reason discussion if exchange of objects between FS en MSTS could be possible, I decided to have a look at adding support for MSTS objects to ModelConverterX. The first results are quite encouraging. I have been able to read the basic geometry and material information. Tricky point remain the textures, since MSTS seems to use its own texture format. In the screenshot below I faked by converting them to DDS before loading into ModelConverterX.

But given these first successes, I will probably try to add this functionality in a future release. I just need to do some more testing with different files.

64 bit version

Until now all of my tools were 32 bit, so even if you we’re running them on a 64 bit OS you could not access the additional memory. Especially for scenProc that was an annoying limitation, so today I took another look at making them 64 bit as well.

In the end it turned out that except from a few external libraries I am using, most of the code runs fine on 64 bit as well. And for those few libraries that gave trouble I found versions that do work on 64 bit as well.

So from the next development release the tool will run as 64 bit applications if you have a 64 bit OS and else they will run as 32 bit as before. Since I made some changes to DLL files I would advice you to completely remove the old version when upgrading to this new version.

When using scenProc with shapefiles be aware that a driver used to read the shapefiles needs to be available as a 64 bit version as well when running on a 64 bit OS. Check out the details on the wiki manual about installing this driver.

In my testing the tools ran fine, but please let me know if you have any issues with this new version.

Material editor and saving textures

Until now the material editor would save a new texture directly for every change you made. So for example renaming the texture or changing the size. When doing multiple operations in a row that resulted in many textures in the texture folder that were not used in the end. And for the user there was an annoying task to figure out which of the textures are actually used.

So I have made a change to the material editor now. From the next development release all the changes you make are first stored in memory only. Once you are done with all your changes you can press the save textures button to save the files to disk. This not only includes all operations on the textures tab, but also minimizing drawcalls. If you try to close the material editor without saving the textures to disk, you will get a reminder.

I hope this change makes it all a bit more user friendly. I plan to make a video tutorial soon to demonstrate all the cool optimizations that can be done now with the material editor.

Drawcall minimizer and repeating textures

Tomorrows development release will contain a couple of improvements to the drawcall minimizer functionality. The main improvement is that you can now also minimize textures that are repeating. ModelConverterX will repeat those textures for you, before inserting them into the combined texture sheet.

As you can see in the image below, there is a checkbox with which you can tell the minimizer if you want to include the repeating textures or not.

By including repeating textures you can possibly reduce the amount of materials in your object a lot more. But depending on how many times the texture is tiled, it might also result in a much larger texture sheet. So you need to find a balance between those two.

Match texture function fixed

I have just fixed the match texture function in the material editor. Since the new material editor was introduced this function was broken, but it is working again. With this function you can look for the same texture, with a different name in the specified texture folder.

I hope to finalize the new material editor in the next couple of days. So that means I want to finish the drawcall minimizer improvements and do some more robustness checks for the material editor in general.

Another nice feature I introduced today is a function that can replace a material with double sided property set by additional triangles. This means a separate triangle is made for both sides. Sometimes it can be more efficient to have a few more triangles if that means you can reduce the amount of drawcalls.

Merge objects

I have added a new function to ModelConverterX, you can now merge objects. After you bring up the form there are a couple of things you can do:

  • You can specify the LOD that should be used for the model you are importing. So this allows you to import another model as a lower level of detail. Or if you give the same LOD as your current object they will be combined.
  • You can specify an offset compared to the current model, so that you can put object besides each other.
  • With the load object button you can load another object from file to be inserted.
  • Alternatively you can also use the list of objects given. This list will show all other objects that are currently loaded into ModelConverterX. So for example if you have loaded a library, all the other models will be shown.

Once you have set all options the way you want, you can press merge to start the merging of the objects.