#Graphics.DrawMesh vs MeshRenderer performance

1 messages · Page 1 of 1 (latest)

potent kiln
#

is the performance of ⁨Graphics.RenderMesh( ... )⁩ comparable to using ⁨MeshRenderer⁩ components?

Assuming I handle GPU instancing the same way that is.
I assume it's slower, but I've never actually compared them directly, it just feels a little scary to (potentially) put so many things into an update loop just for rendering

like, if I made a ⁨MyCustomMeshRenderer⁩ component, where it's just a wrapper for ⁨Graphics.RenderMesh⁩, how much overhead would I pay for not using unity's own ⁨MeshRenderer⁩?

shut pollen
#

If we're talking about cpu costs only, mesh renderer can be pretty optimized on SRPs due to the srp batcher. I think calling graphics render functions might be bypassing the batcher entirely. Then there are other features like the gpu resident drawer, that can boost it further with gpu culling and such.
On BIRP, mesh renderer component ultimately calls something similar to graphics render(or the instanced variant) under the hood, so calling it directly might help reduce some overhead from the gsmeobject+component.

Ultimately, you probably need to test in the context of your project to tell for sure.

agile flume
#

Well, for one you do get rid of that gameobject overhead

#

reason why Terrain doesn't create a gameobject for every single strand of grass

potent kiln
#

hmm, it's hard to tell exactly how people will use it, since it's for my plugin

potent kiln
#

I feel like there has to be some kind of way to do this that supports sorting

#

(specifically tested on BIRP in this case)

shut pollen
#

The sorting seems to be controlled largely by the render parameters. For example:

Unity automatically calculates bounds for all the instances of this Mesh unless you override the bounds using RenderParams.worldBounds. Unity uses the bounds to cull and sort all the instances of this Mesh as a single entity, relative to other rendered Meshes in the scene.
potent kiln
#

nah, because this one has manual sorting of the instances themselves

#

unlike RenderMesh which also does GPU instancing automatically like MeshRenderer, but, it doesn't sort instances amongst themselves like MeshRenderer does

shut pollen
#

The docs don't mention anything about renderMesh allowing instancing. And why would there be a separate call specifically for instancing then?

#

Not to mention that it takes a single objectToWorld matrix, so even if it was rendering several instances, they would all be in the same exact position/orientation.

agile flume
#

Isn't RenderMesh basically instancing anyway? You set the culling AABB for the group of meshes

#

Oh there's an actual RenderMeshInstance you can use instead

blissful chasm
#

There are a lot of downsides to this. RenderMesh is obviously one mesh per draw call, so all your resources are going to need to bind even if they're the same resources the last call drew!
This is relatively slow on the CPU. More than 1ms per thousand calls.

Now, if you use MeshRenderers, obviously it'll be doing batching. But the real benefit comes from being able to use GPU-driven rendering with the GPU Resident Drawer.

This also moves culling to the GPU, and gives you perfect dynamic occlusion culling. That's about as efficient as drawing can get without bindless.

potent kiln
#

hmmmm it really looks like none of the options works across all render pipelines

#

(except for mesh renderers)

potent kiln
#

low key want to drop HDRP and built in RP support lol

#

are we there yet

#

maybe I should use BatchRendererGroup?