Control sort order of rendered primitives (DEF-2530)
britzl opened this issue · comments
Description:
In order to avoid overdraw when rendering things it is important to be able to use the correct sort order for each given scenario. Right now everything is sorted back-to-front, which is great for alpha blended sprites. But when doing opaque 3d you usually want to sort front-to-back to efficiently use the z-buffer. There currently is no way to do this in Defold at this point.
I would suggest adding something similar to this api call:
render.set_sort_order(render.SORT_FRONT_TO_BACK)
where possible options are:
- render.SORT_BACK_TO_FRONT (default),
- render.SORT_FRONT_TO_BACK
- render.SORT_NONE (for when sorting isn't needed and the extra cycles are better spent someplace else)
We want to do something like this, although not necessarily as proposed here. Probably better to set it per material instead of in the render script.
An exploration branch exists where the material can control whether the sorting should be done or not.
Can serve as a proof of concept:
https://github.com/defold/defold/tree/exploration-particle-no-sort
related #5168
I like the API of this and would like this feature to create some performant renderings of many sprites in a scene. The Z-sorting is breaking up the batching and seriously harming my performance (I'm specifically mainly interested in the SORT_NONE option).
I'd be willing to do the plumbing to take a crack at implementing this as well if this API is effectively agreed on.
I'd be willing to do the plumbing to take a crack at implementing this as well if this API is effectively agreed on.
Thanks! There are however additional thoughts regarding "sort order per material" vs "sort order in render api" in this issue: #5168
I think we need to look at the experimental branch shared by @JCash above (https://github.com/defold/defold/tree/exploration-particle-no-sort) before we make a decision.
I need it!
The thing is, I'm assembling a level out of 3D tiles that have only a few different textures.
These tiles have a "world" setting in the material, and I expect them to assemble in several batches.
However, in practice I get HUNDREDS of drawcalls, as these tiles are also shuffled according to the z-order.
Coin_promo_01.mp4
I really need to have a SORT_NONE setting to allow the engine to build a minimum of batches and end up with a minimum of drawcalls.
I will describe the problem in more detail.
I have one landscape cell model.
I put material on it with vertex space = world.
Also, these cells are created through a factory and one of 4 random textures is set on them.
I expect that I will get 4 drawcalls.
Why?
It's simple - I have one model and only 4 textures. The material is set to vertex space = world, so all cells with the same texture should merge into one batch. Since I only have 4 textures, I should only get 4 batches. And only 4 drawcall. Makes sense?
But in reality I have 423 drawcalls!!! \{ O___O }//
...after a few minutes of swearing. I understand that the whole secret is that the batches are split by Z. So if my models have different Z, they won't get into the same batch. Sometimes this is useful when it comes to 2D-graphics and we need sorting in relation to depth location.
But here I have 3D-graphics. Here all sorting is done by Z-buffer.
Here, this method of splitting up the batches only generates unnecessary drawcalls.
A LOT OF UNNECESSARY DRAWCALLS.