Draw Calls optimization, for the engine

[murataka]

The optimization possibly needs to be done by adding or changing some features of the renderer module.

The Scene :
Labels are depth check enabled , modified shader to handle depth drawing correctly.
The hierarchy of the node-tree is not important , just the positions are enough for calling the draw function, But still creates multiple draw calls , for same type of nodes, which can be handled in 1 draw call.
When we place many nodes , which would be optimized , possible the old 2D renderer based algorithms take place , and checks for z-orders of the node.

this creates 2 draw calls , 1 for the labels (bitmap font) , 1 for the boxes (batched)

and this creates 5 draw calls , just changed the node hierarchy , same output , same nodes, same batching optimizations .

If there's a solution you found ( a workaround ) , let's talk about it. If not , this possibly will be a lightning performance improvement for Cocos (when z-orders of nodes do not trigger "sub draw finished", instead calling sub draw calls ,grouped to optimized batching , reagerdless of node-tree levels or z-indexes . ).

[jareguo]

@pandamicro Please look at this feedback.

[pandamicro]

I'm not sure I fully understand your question. I assume you want that the renderer can automatically improve draw call batches by reordering nodes ? If that's the case then we currently don't have any automatic order optimization algorithm.

The thing is there is always trade offs, if the renderer wants to optimize draw call, it has to know the relationship between nodes, whether they can be batched together, whether they overlaps each other, whether they need blend. All these calculations can be very complicated, for a general purpose reorder and batch algorithm from the renderer point of view. It can only be done in the CPU, with JavaScript implementation, it could be even worse than more draw calls.

I'm not saying we shouldn't do any improvement, it's just easy to see benefits and miss the trade offs. I can share what we are gonna do in 3.x

1. You can have multiple UI view that overlaps each other, each one have its own priority, so you can control the order from Canvas level.
2. You can have multiple camera to filter different node, regardless of its hierarchy relationship, camera priority is always more important
3. We will have builtin scene management in native engine, it will mainly for culling, but might have further improvements related to batching

[murataka]

Using 2 cameras , culling enabled for same type of materials did not work ...

[murataka]

same scene , 2 draw calls .

[murataka]

Here you can test it (change the orders or child parent relation of boxes ):
perftest_creator2.4.3.zip

[pandamicro]

We are discussing different issues here actually, my previous response was for 2D objects, sorting and batching are indeed very different when we handle 2D or 3D objects.

The reason is that 2D objects need to be rendered in order so that the render order and the blend through transparent pixels is correct (objects overlaps a lot in 2D UI), so we can't simply reorder them with material hash. As for 3D objects, we do reorder them like what you suggested (in 3.0), please take a look at the compare functions, they are invoked in the forward stage. So our 3D objects will no longer break batches as your test in v2.4.

For 2D objects, we are also working on other optimization strategies for 3.0

[murataka]

Thank you very much for the detailed response.
I am looking forward for the new version .

Have a nice day !