Search Unity

  1. Get the latest news, tutorials and offers directly to your inbox with our newsletters. Sign up now.
    Dismiss Notice

Is Graphics.DrawMesh a performance issue?

Discussion in 'Scripting' started by UnbridledGames, Apr 19, 2021.

  1. UnbridledGames

    UnbridledGames

    Joined:
    May 12, 2020
    Posts:
    137
    I'm helping a friend out with some code, and his game has large sections of terrain being drawn by Graphics.DrawMesh. Never saw the command before, googled it, and it seems it renders the mesh every frame in the position/rotation required. I'm a big fan of efficient coding, and while on the surface I see how that could be useful in his situation, at the same time, that mesh isn't changing that often. I'm having a hard time seeing why that should be used instead of just sticking the mesh on a GameObject.

    Is there a difference really between having a MeshRenderer on a gameObject or calling Graphics.DrawMesh every frame? I'm pretty ignorant of how graphics are handled on the backend. But if it's doing what I think it might be, it seems like a huge waste of CPU time...?
     
  2. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    2,388
    As with everything, it depends. Drawing an asteroid field of a thousand asteroids with the Graphics.DrawXYZ functions will be significantly more performant than having a thousand GameObjects with MeshRenderers on them. But for one asteroid, who really knows -- and it probably doesn't matter at such a small scope -- so you'll have to elaborate on how many terrain cells are being drawn this way and what exactly you even mean by "terrain" in the first place.
     
unityunity