Inconsistent draw calls

1

I have noticed this behavior in my game and want to know how CGE count draw calls in this scenario (and how to reduce it). See the clip https://youtu.be/cqgi8U--3dY and the following timestamps:

  • 0:00: Empty map, draw calls = 4
  • 0:14: Added a tile (grassland 0), scene increased by 1, yet draw calls increased by 2 (6) (why 2 and not 1?)
  • 0:26: Added another tile (raw meat), scene increased by 1, draw calls now only increased by 1 (7)

Some information:

  • Both grassland model and raw meat model have only 1 mesh. This can be easily validated:
    • The editor does static batching (when I add multiple grassland in the clip, draw calls does not increase, and my batching code only works with 1 mesh).
    • castle-model-viewer reports draw calls = 1 for both models.
2

  • See code below this line to know exactly how it’s counted. Our intention is to increase Renderer.Statistics^.DrawCalls exactly as much times as glDrawArrays or glDrawElements was called.

  • Possible explanation: Possibly adding grassland has some additional transparent shape? Or an extra material? Anything that requires 2 draw calls?

    The fact that it’s batched into 2 draw calls (even for multiple grasslands) doesn’t yet eliminate above possibility.

    If Castle Model Viewer reports 1 draw call, maybe in game you activate slightly different rendering options?

    These are just ideas :slight_smile: If you can send the code + assets, I will be happy to investigate.

3

Both models run through the same batching code with same rendering options.

The logic of the batching code is basically:

  • Load the model to the scene, but clear up vertices / indices / texture coords, only keep the material.
  • Then use the same scene to merge vertices / indices / texture coords everytime another tile is added to the map.

Since the base model only has 1 shape, I don’t understand why there’re 2 draw calls/1 scene when all the code does is empty out the data from the base scene (while keeping the material), and merge data from other scenes to the base scene.

models.zip (8.9 KB)

I can send the code via PM, but most of the logic is done using my own scripting language (the batching code is done on Pascal side btw)

Edit: Since I am on vacation and this laptop of mine kinda sucks I can’t really run any GPU debugger on this one.

Edit2:

image
image641×118 10.6 KB

4

Okay, since RenderDoc fails to do the job, I managed to get Nsight Graphics up and running on this Linux box.

Click to view images

Screenshot_2025-04-02_05-46-50
Screenshot_2025-04-02_05-46-501544×892 33.9 KB

Screenshot_2025-04-02_05-47-00
Screenshot_2025-04-02_05-47-001544×892 35.6 KB

From what I see in the images above, the batch somehow gets rendered two times before any transparent objects are rendered on screen, so I guess they belong to the same render pass, which is quite confuse to me.

Edit: The “yellow square”, which represent the player, also get rendered 2 times.

5

Okay, I found it. One of the light sources has the Shadows property set to True, which in turn forces these non-transparent objects to render more than once. :smiley:

I thought setting CastShadows to False would prevent this from happening, but I just rechecked the documentation and saw that it does not affect shadow maps.

Besides, isn’t the Shadows property only activating shadow volume for now, which theoretically should not require the same object to be rendered multiple times?

6

Oh, cool, so solved.

To add some background:

  • The CastShadows right now affects only shadow volumes (though we want it to apply to shadow maps too in the future, right now they use a different setting, TAppearanceNode.ShadowCaster ). See TODO in docs of CastShadows.

  • And Shadows on light sources does activate shadow volumes.

  • Shadow volumes do require multiple passes, see here where we call RenderOnePass multiple times, with different subset of items. In particular, the objects that may receive shadows have to be rendered 2 times, once with the light=off, once with light=on (and stencil buffer allowing only pixels where the light shines). This is independent from “being a shadow caster” (which determines whether we render shadow quads for the shadow caster or not). Just receiving shadow volumes (whether you also cast them or not, doesn’t matter) means we need to render it 2x.

7

Guess shadow volume is expensive after all - We still have to render objects 2 times while having to calculate conical area for any shadow casters.