Drawcall batching, a no-brainer?

Ever since the release of FSX SP2 enabling drawcall batching has been a popular method of increasing the performance of scenery. The basic idea behind drawcall batching is that the scenery engine will gather all polygons with the same material, even if they belong to different objects, and then render them in one go. This eliminates the overhead of switching material and texture settings multiple times and therefore improves the performance.

But is it a good idea to always enable drawcall batching on objects? For a while we already know that drawcalls with too many polygons in them give trouble. They can result in disappearing objects for example. So in that case you better turn off the drawcall batching.

Last week while debugging an issue reported on the forum I found out that drawcall batching can have one more negative side effect. It turns out that when objects are used at higher altitude, the drawcall batching results in an offset of the position of the object. I never noticed this myself, since I’m from the Netherlands and always test my objects at sea level. But when you make scenery in a mountainous area you will for sure encounter this. So also in that case it might be better to turn off drawcall batching.

By default ModelConverterX has drawcall batching enabled, but you can easily disable it in the exporter options. If you encounter any of the issues described above, it might be a good try.

So it turns out that drawcall batching is not the magic performance solution we have thought for a long time, but if you are aware of the limitations you can still make good use of it.

3 thoughts on “Drawcall batching, a no-brainer?

  1. GianP says:

    Hi Arno,
    this is a well known issue.
    Solution? Yes…
    Just compile every object with an empty animation block. Don’t ask me why but this fixes the issue, at least in FSX & ESP.

    cheers
    GianP

  2. Alex Goff says:

    I’ve been tracking this bug for years now, it plagued me while working on West Yellowstone Airport which sits at about ~6500ft ASL. The shift is roughly 1ft for every 1000ft in elevation. It’s in Prepar3D and Prepar3Dv2 as well but it does not shift by the same amount.

    I believe it is a floating point error somewhere in the simulator engine that causes increasingly inaccurate placement as the elevation value grows.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.