gPoly (no) progress report

Just a quick note that the gPoly development has been slow recently. About two weeks ago I worked a bit on the texture mapping on the polygons, but since then I have been kept busy with other things. Mainly work, but on the other hand I have also been working on the ModelConverterX tool to improve the COLLADA conversion so that SketchUp can be used as a modelling tool. At the moment that has a slightly higher priority, but after that I will return to the gPoly development again.

Modelling for FSX using Sketchup

One of the topics that is discussed often lately on the FSDeveloper forums is using Sketchup to model for FSX. The good news for those of you who think that the learning curve of GMax is a bit too steep, is that you can use Sketchup as well if you want to model some scenery objects for FSX. I should directly note that if you plan to make an aircraft than Sketchup will not be of much use to you, since you will still need GMax to do all the animations and other advanced features that an aircraft needs. But if you want to model some scenery objects (without animations), then using Sketchup is certainly an option for you.

In this blog post I want to discuss some issues that you need to be aware of when modelling using Sketchup, as there are still some open edges. Later I plan to write a tutorial about this as well, but I need to do some more research on a few topics.

How to export to FS?

You can not export directly from Sketchup to the MDL format that is used in FSX for objects. But in Sketchup 7.1 you can export directly to the COLLADA DAE format (in earlier versions this was not possible in the free version, only in the Pro version). Once you have the COLLADA file you can use my ModelConverterX tool to convert the COLLADA file to a MDL object for FS. This MDL object can then be put into a library and positioned like any other MDL object.

But what about the textures?

Using the ModelConverterX it is indeed easy to convert the geometry of your object, but how about the textures? Most of the texture you applied in Sketchup will be exported a JPG files and that is not a format that FS can read. So you will have to convert these manually to the DDS or extended BMP format as used by FS. Also be aware that the textures as exported by Sketchup not always have sizes that are a power of two (you know 256×256 or 512×1024 or …) so you might have to resize the texture as well before you can use it in FS. I am working on a ModelConverterX feature to assist you in these texture conversions.

Watch out with the drawcalls

With Sketchup it is very easy to create your geometry and it also comes with a library full of materials, for example bricks or roof textures, that you can just drop onto your object. But wait a second, that means you will end up with a material that uses many textures (and maybe also some colours) and that will not give you best performance in FS. Each of these will add an additional drawcall to your object. So I would not advice that you model like that for FS.

But how should you model then? It is best to try to use only one texture sheet for all parts of your object. So don’t use these materials and do not apply a colour to your polygons. Try to use the same material on the entire object. I know it will cost you a little more time to map the material correctly, but it will pay you back in a better performance within FS.

Also be careful not to use the “make unique texture” option in Sketchup, as that will cut your texture into smaller pieces and then you still end up with multiple textures (even if they came from the same texture sheet).

Checklist

So sum up all these items and place them in a checklist you would get the following lists of items that you need to do when you want to use Sketchup to model for Flight Simulator:

  1. Create your object in Sketchup. Be aware of the performance implications when working with materials, so try to use one texture sheet for the entire object if possible.
  2. Export your object from Sketchup to the COLLADA DAE format.
  3. Import the DAE file in ModelConverterX and export it again as FSX MDL file.
  4. Convert the textures that Sketchup exported to a format that FSX can read (DDS is preferred). Be aware that you might have to resize them so that the sizes are a power of two.
  5. After that you can use the MDL file and the textures like any object for FSX, so you can put it in an object library and place it with your favourite object placement tool.

And most of all, have fun! In the end you should notice that it is a lot of fun to make your own objects for FS and if you found the learning curve of GMax to steep, then Sketchup might be more fun for you to use.

Texture conversions

In the last days there has been a lot of discussion on the FSDeveloper forum about converting COLLADA objects for use in FSX. One of the issues the users are facing is that many COLLADA models use textures in formats that FSX can not read, for example JPG files. So there is clearly a need to address this during the conversion.

I have not finished it, but I am working on adding support for texture conversions to ModelConverterX. In the next development release you will find a texture converter tool in the special tools menu. Although I made it more as a test tool to see if saving textures is working, I think it can also have practical use when converting your models. For example when you model still uses R8 textures that you want to convert to BMP or DDS. I should say directly that saving to DDS or extended BMP formats is not yet working, but I hope to have that feature very soon as well. So below you see a screenshot of the converter with a texture loaded.

Using the radio buttons you can select which channel you want to see. Another interesting feature, especially if your model using the BitmapMode command to determine which colour should be transparent, is that you can set the alpha channel based on a colour. So in this case if I would select black as the transparent colour you would get the alpha channel as shown below.

As I said, I hope to add support for DDS and extended BMP textures soon, since these are the primary formats used by FS. After that I am also planning to add another tool to ModelConverterX that allows you to easily rename, convert or resize multiple textures at once. Because this texture converter tool I added now is not really of assistance when you have a COLLADA model with a few dozen of textures. I’ll keep you informed about the progress on these other features I have in mind.

Video tutorial about performance

Tomorrow there will be another online video tutorial on the FSDeveloper LiveStream channel. The subject of this tutorial is performance for 3D objects and the tutorial will start at 22:00 CET (21:00 UTC). The following topics will be covered:

  • Definition of concepts important for the performance: levels of detail, drawcall and texture vertex
  • Performance tips how to make best use of these concepts to optimize your performance
  • Explanation of DXT compression for textures, which types are available and how does the compression work (and what does it do for the quality)

I am almost finished with the preparations, so hope to see you tomorrow for this tutorial!

gPoly status update #6

Today I have been making some progress on gPoly again, so time for another status update. The first part I worked on is the user interface, especially the texture library that contains the texture you can use on your polygons. And also other improvements like the interface used to define new projects.

But most of the time I spend on functionality to import shapefiles. Initially I had not planned this for the first version, but since I had some accurate vector data and imagery of the same airport, this would allow me to verify that the imagery is positioned correctly. As you can see on the screenshot below I think it is quite accurate, since the markings line up very well. So I am happy with that and can move on to some other features tomorrow.

ModelConverterX and LODs

It’s a little bit ironic, after all the effort I put in the LOD Creator functionality of ModelConverterX. But today I found out that the LODs were not really working in FSX SP2 when you exported the FSX MDL files. This is because of the drawcall batching functionality that I wrote about in the previous post. There is a solution for this that breaks the drawcall batching.

So I have now added a new option in ModelConverterX that allows you to specify if you prefer the drawcall batching or working LODs. By default the LODs will be working. If the object has only one level of detail the setting has no influence, in that case the drawcall batching will always work. If the object has animations the setting also has no influence, since these prevent the drawcall batching in any case (and thus the LODs will work).

This fix will be available in the development release of tomorrow. So enjoy your LODs even more from now on!

LODs versus drawcall batching

Since MS introduced the concept of drawcall batching in SP2 of FSX there has been a lot of discussion going on about levels of details still working or not. In the end it comes down to a choice between either having LODs working for your object or having drawcall batching. The MDL files that the GMax gamepack makes will have working LODs by default (and thus no drawcall batching). Since I don’t use 3DS Max I am not sure what the default situation is there. But by compiling with an empty xanim file and the /XANIM flag in XtoMDL you can ensure that your LODs will work.

So this brings us to the choice do we want LODs working or do we want the drawcall batching to work? Today I did some experimentation to try to answer this question. What I did is the following. I made a test object that has three levels of detail, a sphere, a cylinder and a cube. I then compared the performance of a grid of 486 of these objects placed in the situation with LODs working and in the situation with drawcall batching working (but always the most complex LOD showing). And to add another dimension to the test I then varied the amount of triangles in the spheres, cylinders and boxes to see which effect that has. Below you see a screenshot of the test situation.

Sounds complex all this? Let’s take a look at the results I got:

Triangles

Drawcalls

Framerate

744440

486

19

1928448

1

11

 

 

 

435072

486

25

1073088

1

20

 

 

 

259704

486

25

594864

1

26

 

 

 

54456

486

25

139968

1

36

Each row of two results is the situation with a different complexity of the object for the situation with the LODs working (486 drawcalls) and with the drawcall batching working (1 drawcall). So it seems that the conclusion from this is that if you have an object that will be used in many places (many instances) that you are better of without the levels of details, but with the drawcall batching working. Only for complex objects (when more than 600000 triangles are rendered in the scene) it seems that using the levels of detail gets the upper hand again. But I doubt there are many autogen or generic objects that are so complex and placed so often to reach such limits.

I am not completely sure yet what this means for custom objects that are only placed in one or two locations. For those drawcall batching will not bring so many benefits, unless the same material is used on many of those custom objects. So I guess for them using levels of detail to reduce the triangle count is the best choice. But I will try to do some more testing to see if I can verify that.

As I mentioned, these are my first results and I am not sure if the conclusions are correct (yet). So I would be happy to hear your thoughts or ideas about this subject. I have also posted this information on the FSDeveloper forum, so please join the discussion there if you have feedback.

 

ModelConverterX tutorial on Wiki

The ModelConverterX tutorial I gave this evening on the FSDeveloper LiveStream channel, has also been uploaded to the Wiki now. So on both of these places you can now review this tutorial.

Unfortunately I had a few bandwidth problems while recording the tutorial, so I had to restart two times. Sorry for the inconvenience for those who were following the tutorial live. Luckily it seemed there were not so many people watching live. When you watch the tutorial on the Wiki you won’t notice these trouble of course. Another comment I got from Nick halfway through is that the sound volume was maybe a little bit low, I will try to fix that for the next tutorial on Friday, when I will be talking about performance related issues (drawcalls, texture vertices, DXT compression).

Criel-sur-Mer

The last few days we were in Normandy, around Criel-sur-Mer. Just a few days away to relax a bit after a busy year and trying to think as little as possible about work or flight simulation. So when it was a nice and sunny day we decided to go for a walk along the coast and over the beautiful cliffs.

And what do you think we stumbled upon during our walk? A nice little airstrip, on top of the cliff and quite close to the coast. I think the airstrip is used by a local flying club, probably with ultralights, but I am not sure about that. We saw one ultralight flying that day as well.

Apart from a few white markers and the little sign (see the photo to the right) there was not much that identified this piece of grass as an airstrip. I think it must be pretty hard to spot something like this from the air, it really blend well into the environment. I found it back on Google Maps though and you can also see the markers there.

For many FS sceneries it is still a challenge to blend that well into the environment. If there was a nice photo scenery of Normandy for FSX (I am not sure if there is actually, I am not so up-to-date with French sceneries), would this not be a fun little airstrip to fly from while exploring the coast? It could be a nice little side project to make if I ever get bored.