In our project we've been constantly fighting against Unity's stubborn preference to strictly render opaque objects from front to back in order to minimize overdraw. While this sounds fine on paper it ultimately results in slow rendering times due to increasing the number of draw calls. In the case of rendering a densely populated scene like forests and cityscapes, you're reusing the same model over and over, thus you may use GPU instancing or dynamic batching to draw all of these objects very quickly with one draw call. However, Unity's very strict minimization of overdraw philosophy prevents developers from being able to utilize these drawcall minimization optimizations in most real-world rendering situations (without using hacks and work arounds). If you have two different types of meshes scattered about across a terrain say, Unity could draw all instances of these meshes in two draw calls if it wanted to. However, instead it insists on drawing by distance, and thus draws one instance of A, then another instance of B, then maybe a couple instances of A, and a couple instances of B, and so on, resulting in many draw calls and awful performance. One horrible solution we come up with is to put each different mesh+material combination into different layers of the Render Queue (Think Opaque, Transparent, Overlay, etc.) bypassing distance rendering order, so that all the things that can be batched or instanced will be rendered consecutively. This works, dramatically increasing performance. However, we quickly realized that using property blocks causes Unity to ignore material-specified queue order, thus reverting to the queue setting specified by the shader, thus reverting everything to slow front-to-back ordering. The next, more horrible solution, was to not use property blocks (even though we kinda needed them) and instead achieve the same effect by massively duplicating materials in the project via an automated build step. This is pretty awful, but it prevented Unity from ignoring the render queue order specified in the material. (Please fix this bug!) However, a better solution is in the works with using Renderer.sortingOrder in the same way we used the render queue to bypass Unity's aggressive sorting. Hopefully, when we start using property blocks again, Unity will not decide to throw away the sorting order we specified. Anyway to summarize - 2 issues: 1. Unity needs to think of a better scheme for managing the trade off between overdraw and draw call count. Keep in mind that even though graphics APIs are getting lighter and the cost of draw calls will decrease, GPU speed and thus the cost of overdraw always drops over time according to moore's law, a phenomenon that has ceased with CPUs. Grouping things into chunks may be an option (where you can specify chunk size, with a chunk size of 0 being the behaviour we have now). It'd render the chunks from front to back, but within chunks, batchable or instancable objects are drawn together: DrawCalls.OrderBy(Distance).OrderBy(BatchingCriteriaLikeMaterialAndMesh).OrderBy(ChunkIndex) 2. Enabling property blocks will cause unity to ignore the render queue specified by the material, reverting to the render order specified by the shader instead. While in our case we used this as a hack for performance boosts, this could break some people's visuals unexpectedly. Sounds like a bug as well.