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.

ModelConverterX video tutorial

Just a little reminder that in two days there will be an online video tutorial about ModelConverterX. I think tutorial I will give a quick introduction to the tool and after that I will show how you can use it to convert old API macros into FSX MDL files or how to import them into GMax for further editing.

So you are all invited to join this tutorial on Saturday 2nd of January at 20:00 CET on the FSDeveloper Livestream channel. See you there! And if you can’t make it the tutorial will be available on the Wiki afterwards as well.

gPoly status update #4

Time for another gPoly status update, today I have made some good progress on the tool again. The first part I have finished is the display of the GeoTIFF background image, this code seems to be quite optimal now, so that even with big images you can pan and zoom without too much delay. What I still have to do is verify the accuracy of the geo position, I think I need to render some reference information (of which I know the position) over it to do this. Another related feature on the todo list is the ability to make images georeferenced when they are not yet.

Today I also worked quite a bit on the user interface, especially the part that allows you to manipulate the layers in the project. Each layer can hold a background image or a set of features (polygons, lines, etc). Below is the screenshot of the current status.

gPoly status update #3

This evening I continued on the gPoly tool. The focus was again on the display of the background images, since they are a very important feature when drawing ground features or when checking if they are in the right location. I made some good progress and for small to medium sized airports it is working fine now.

But when I try to load the high resolution background image I have of Schiphol things go less smooth, especially when you zoom in far and the highest resolution needs to be loaded. So there is still some work to be done when selecting the resolution that should be displayed, but progress is being made. I should note that the background image of Schiphol is a GeoTIFF of almost 4 GB in size, so it should be expected that things will never be super smooth when working with such a big file.

Day or night?

Tonight I have added a nice little feature to ModelConverterX again (it will be in the 1.2 development release tomorrow). You might wonder what it is? You can now choose to render your object in day or night view. The night view allows you to preview the night textures. Here is a little screenshot of one of the default objects.

It is not yet finished, since I just display the night texture now. Whether it is a nightmap or a lightmap is not yet taken into consideration. So that gives some room for future improvement. But this will allow you to check how the object would look during the night.