Search Unity

Overdrawn pixels vs many polygons, which affects performance the most?

Discussion in 'General Graphics' started by blablaalb, Mar 18, 2019.

  1. blablaalb

    blablaalb

    Joined:
    Oct 28, 2015
    Posts:
    28
    I know that having overdrawn pixels is not desirable as well as having many polygons since they can decrease performance. Often when I model I have an option to decrease the number of polygons by having disconnected polygons over. For example, considering this:

    (Let's imagine it has more turns that are not visible in this picture). I can decrease the number of polygons by having a pathway as a single disconnected face:

    As a result I would have less poly-count, but the bottom geometry would be overdrawn in many areas.
    Or I can model this as a single continuous mesh. As a result I would have more poly-count, but no overdraw:

    I very often have similar situations and I'm wondering which of these would be more performance efficient and cause less performance decrease on mobile devices?
     
    Last edited: Mar 18, 2019
  2. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    7,329
    There's no one answer. It's totally dependant on the GPU and what else is in your scene.

    Is the current mobile device good at dealing with opaque overdraw (many of them are), then overdraw may be faster. Otherwise more tris/vertices may be faster.

    If your current scene already has a lot of overdraw and is becoming a performance bottleneck, then more tris may be faster.

    If your scene has a lot of tris and is becoming a performance bottleneck, then more overdraw may be faster.

    Both options may not be the "best", and a middle ground of a simplified dirt path geometry that reduces the overdraw with as few extra tris as possible may be the better option.


    The only way to know is to try them.
     
    neoshaman likes this.
  3. Sh-Shahrabi

    Sh-Shahrabi

    Joined:
    Sep 28, 2018
    Posts:
    54
    Also for VR, it is always mentioned fill rate is heavily effected by the fragment side of the pipeline and overdraw. Combining the two mobile + VR in the latest test I actually got better numbers by having a mesh parsed in smaller segments, which use the same texture + material just to avoid opaque overdraws within the same chunk. But then again if the GPU commands are not processed on the render thread but the main thread, then having more chunks can lead to longer sorting and culling time on the CPU. So as bgolus said, it depends on the situation.