EDIT: Just to clarify for anyone stumbling over this, I quickly found out that MDI doesn’t actually work even with RenderMeshIndirect, even though according to the docs it should. And I really want it to work.
To achieve Multi-Draw on Dx12/Vulkan, you can combine your meshes into a single mesh and submit it with RenderMeshIndirect using a CommandBuffer with multiple commands, each with the correct vertex/index-offsets & -counts for their corresponding submesh.
With RenderPrimitivesIndirect, you basically do the same, but instead of letting Unity bind the vertex- and index buffers via a mesh, you bind your own buffers (via the material set in RenderParams).
Overall, the approach stays the same: Combine the vertex and index buffers, then render all instances at once with their respective offsets. Or so I thought. Yet, when using RenderPrimitivesIndirect, Unity issues one draw call per draw command in the command buffer (labeled Draw Procedural Indirect in the frame debugger, tested on both dx12 and vulkan), where as per documentation and this post multi-draw can be used with RenderMeshIndirect.
So my question is, why does one work but not the other? And is there some way to get it to work?
I don’t want to use RenderMeshIndirect since that would require using either readable meshes or gpu readbacks, both wasted memory and performance. I’d rather combine the buffers directly on the gpu with a compute shader.
Saw unity webinar “Optimize Rendering Performance with Unity’s Batching Techniques” today,
they mentioned multidraw low level api, to draw different meshes in 1 draw call,but apparently not exposed to users…
Yeah if they’re already using it internally, they should absolutely expose it. They wouldn’t even need to change the api, as RenderMeshIndirect already takes arguments as if it worked. When I checked Vulkan draw calls on Nsight, they would literally just need to adjust the arguments to condense these four draw calls into a single one, as the buffer is already set up for multi draw.
Disappointing. The “resolution” is also vague enough to not clarify whether this is indeed a bug or a missing feature with erroneous documentation. Meanwhile, I have hundreds of empty, useless draw calls in my project and no way to get rid of them simply because Unity won’t forward the api calls correctly. Surely it wouldn’t be too much work to fix this? Please?
I’d also like to see this implemented, especially in the URP / SRP rendering path.
Anything to do with indexed indirect rendering in URP using ShaderGraph seems to be completely broken / hidden away / just not implemented. Maybe if Unity exposes some of the internal API for this and other Graphics commands it could help niche use cases like those as well.
They have once again slapped a big red “won’t fix” on the report with no notice, no explanation whatsoever, just as it became the most voted “active” report. I actually cannot believe this, MDI is integral to modern rendering pipelines, and it’s not like unity is not acknowledging the demand for gpu driven rendering, given that they are woking on their gpu resident drawer. So what’s keeping you from doing the much simpler thing of exposing the MDI api calls to us via Graphics.RenderMeshIndirect and the likes? You are falling so behind the times it’s not funny anymore.
Really my three months of work just turned out to be the biggest waste of time I’ve ever experienced. The whole idea behind my renderer was to submit all draw calls for multiple meshes at once whenever possible. I had to fix countless issues and come up with many solutions, only to realize I was digging a hole in the wrong fuc****ing place. I trusted the documentation (what else to trust); it said multi-indirect draw calls is possible, and I took that for granted. I never imagined we were dealing with kids instead of engine developers!
