You might already have read on the blog of Owen or Nick that the MVP summit of this year is starting soon. Unfortunately I will not be able to be there. That is a pitty, as I would have loved to meet Owen, Nick and the other MVP’s in person. But after traveling to the DevCon last November I have to save some traveling budget again, so maybe next year I can be there.
What about a 3DS exporter?
During discussion with a ModelConverterX user recently the subject of being able to import the objects into GMax or 3DS Max came up. If you want to continue editing your work that is indeed something that would be very useful. Now I did take a look at the 3DS format and it seems very well possible to write an exporter for it. Actually in about one evening I already made the base of it. Below you see a screenshot of a museum object that I imported into GMax from a 3DS file exported with ModelConverterX. As you see the materials are not yet there, as I have no written them to the 3DS file yet, but the geometry is getting through very well already.
In the next few days I hope to extend the writer further to also include the materials and other more advanced features. Of course an export-import process like this will never be perfect. For example the original parts that you had in your modelling tool will not always appear when importing in GMax. That is simply because this kind of information might not be stored in the API or MDL file that you imported. But at least it might be better than starting completely from scratch, especially if you only want to make some minor changes.
One other issue I am thinking about is the more legal part, as this would allow people must easier to edit other people’s work. That might give a copyright problem, although it is always the question if the user or the tool is to blame for that. At least it is something that we have to be aware of.
But in total I am quite enthusiastic about this, it might even help us to get our models out of GMax when that tool is no longer supported for FS in the future. By being able to write in a common format as 3DS the way to import into other tools is a bit more open.
New ModelConverterX release
I have just released the next alpha version of ModelConverterX. The main new feature is the support for the SCASM binary commands that are used a lot by FSDS. This feature alone already would justify a new release, as this will greatly improve the number of SCASM macros that can be converted correctly.
Besides that I have added a new object reader, that can read FSX MDL objects. This reader is probably not so useful for most users, as they want to export to FSX MDL objects, not import them. But if you want to convert some FSX MDL objects to OpenFlight for example it might be useful. As this is an initial version of the reader, it will not read all MDL files at the moment. But objects without animations or other complex stuff should work fine.
To get the latest version and read a bit more about the future plans, please take a look at this thread on the forum.
Hey, is that a manual?
I think almost any programmer will tell you the same, writing the manual or documentation for some work he has done (or is doing) is not the most fun part. So usually that part lacks a bit behind the program being made. For me that is also the case. Especially for the tools that are still in beta phase, the manual is often lacking or very minimal.
But today I changed that a bit, as I wrote a quick manual for the DrawCallMonitor tool I released a while ago. You can find this manual on the Wiki. Although it is a quite simple tool to use, I hope the manual provides a little more background information.
As this manual was short, it was easy to write. But I will promise you I will try to expand the ModelConverterX manual as well soon.
Start of spring
Today was supposed to be the start of spring, but looking at the weather outside (snow, rain, cold) it seems not really to be the case yet. There is even some chance that we get a white Easter this year, maybe that can compensate for the lack of white Christmases lately.
But this might also have a positive effect, I might have some more time to program a bit during the Easter days now. Then I can catch up with the time I lost when the flu kept me in my bed two days this week. Tonight I already continued a bit on the ModelConverterX tool and basically added the support for the binary SCASM commands that FSDS uses a lot. It is working now, but the code needs some cleanup later this weekend. With this basic I can also continue on the FS2004 MDL reader and a BGL object reader. So there is more to come.
SCASM and binary commands
The next feature I will be working on for ModelConverterX is the support of the SCASM commands that enter the binary BGL/MDL code directly. With these commands you can enter certain hexadecimal values directly in the created file.
You might expect that this is a feature that would only be used by the real expert who wants to create some very special functionality, as you can easily screw things up if you are not sure what you are doing. But that is not the case, these commands are used quite often in API objects.
Especially FSDS makes a lot of use of them. If I remember correctly, this is because by the time FSDS was released a newer SCASM version was needed to be able to use the LoadBitmap and RGBSColor commands. But Abacus was also selling their ASD tool which come with an older version of SCASM. So to make sure that ASD could work with the macros generated by FSDS, FSDS had to write the LoadBitmap and RGBSColor commands with those direct binary commands.
The code I have started to write now will be able to analyze those binary commands, so that ModelConverterX can process them correctly. And with the same code I will also be able to read objects directly from the BGL file later on. So that might be another useful new function.
ESP as Serious Game
ESP seems to be getting more and more attention. I just came across this post on this site about serious gaming. I think it is an interesting development that ESP gets know better.
Real-time rendering
Recently I bought an interesting book, Real-time rendering. I have not completely finished reading this book, but it contains a lot of useful information. For example I have found there solutions for some problems I had while working on my ModelConverterX tool. But the explanation of how the rendering process works also give a better insight on what has an influence on the performance when rendering. This is not only interesting to understand better how FSX works, but that is also something I can use at work when dealing with our image generators there.
Multiple objects
Yesterday I continued working on a new feature for ModelConverterX that was high on the wishlist for a while. The ability to read in SCASM files with more than one object defined inside. So for example this would allow you to read in a SCASM object library definitation or just a SCAMS file that contains multiple objects (multiple Area/EndA commands that means).
I have made good progress on this feature, although there are still a few things to improve before it is ready for release. But I think this could be a useful feature for a lot of people.
Transparent textures
Today I have been doing some work again on one of the main features still missing from ModelConverterX, transparent textures. In the FSX MDL format it is no longer enough to add an alpha channel to your texture file. You also have to specify in the material that is used on the object that you want to use that alpha channel. So that is something the user will have to specify when he converts an object with ModelConverterX. To do that I have added a form to edit the material properties. This will also allow people to easily add night textures to objects that did not have them before for example.
At the moment I am still fixing some minor bugs in the X file that give some drawing order problems, but hopefully I can get a new version of ModelConverterX with this functionality added online this weekend. With the support for transparency added I think most SCASM macros that don’t use special code should be convertable.