Search Unity

Question Batching didn't help reduce my render time, what do I miss or not understand?

Discussion in 'General Graphics' started by AstrooLabe, Jun 1, 2021.

  1. AstrooLabe

    AstrooLabe

    Joined:
    Jan 3, 2019
    Posts:
    14
    Hi there, I think I need a little help to understand what I am doing wrong.

    I'm working on a prototype of city builder and I want to add a terrain editing feature based on blocks of diverse shapes and color.

    So, I tought that using batching on the blocks would help reduce the render time and, if I indeed have a low number of drawcalls thanks to the batching, for some reasons the render time still stay as high as before and go up if I try to render more blocks.

    How can I limit the render time in these conditions?
     
  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    12,352
    There's a lot to unpack here. What exactly do you mean by batching, or render time?

    These might seem obvious, but there's multiple different kinds of batching. I'm going to guess you mean dynamic batching, which can improve GPU utilization at the cost of increased CPU usage as it has to combine meshes on the CPU. If you're currently CPU limited, batching is unlikely to be a benefit. Dynamic batching is also "dumb" in that it will rebuild the batched mesh every single update even if nothing changes.

    If by render time you're referring to the value in the stats window, that's the CPU render thread, which may increase when using batching since, as mentioned, it now has to combine meshes. It does not show anything related to the time the GPU is taking unless you're using Vsync or otherwise gets so far behind that it tells the CPU to wait.

    If you're already GPU limited in terms of total vertex count or shading complexity, batching also won't help since you're still rendering the same number of vertices as before.


    Assuming you're not GPU bound, it's often beneficial to implement batching on your own. Split up your terrain into grid tiles made of several blocks and manually combine them using Mesh.CombineMeshes() and only update a tile when something changes in it. You may also want to look into greedy meshing, or even totally custom mesh combining, so you can weld vertices between blocks to reduce the vertex count if that is a problem for GPU performance. The reason to use tiles rather than combining the entire terrain as one piece is it allows frustum culling to still work, meaning the CPU can cull tiles that are not visible and thus the GPU isn't spending time calculating a lot of vertices it can't see.


    However the real answer to the question is ultimately "it depends" as there are so many possible reasons for why your framerate might not be good. The only way to know what is for you to profile it yourself and find out what's taking a long time. After that we may be able to assist more. Just be aware the answer may be an unappealing "render less stuff".