BatchRenderer2D Optimization about sparky HOT 5 OPEN

What if you want a specific draw order in your layer? Say, Object A and B are both on the same layer, but you want B drawn over A whilst B having a lower texture ID?

from sparky.

Don't forget that this is a 3D engine so even if you use it to render 2D sprites their positions are still represented by 3D vectors. Easy to then use the Z coord to deal with this.

As a rule, the rendering of the scene should always and only be dictated by the data, not the order you submit things in.

from sparky.

Could you provide a example? Where and what vector do I need to sort. (i'm just being curious as i don't know how long the series are being halted for)

from sparky.

Ossadtchii - To my understanding this is not just a simple sorting of vector that ed is suggesting. It's also a wonderful idea and I will personally be implementing into my own engine (thank you and I can't believe I didn't think of it, but I guess that is why I went looking here for suggestions). In order to do it your self, you will need to change the submit method to store some key information about the renderable being submitted (I would use a struct that stored the shader id, the material id / name (if you are using them), and the texture id) alongside a pointer to the renderable and I would store that in the struct as well. Now when it comes to the flush method I would do as suggested and go down and sort the vector storing all of these structs first by shader id, then material id, then texture id. At the end you then just render the renderables in the new order obtained by this newly sorted vector. But I don't believe it is as simple as needing to sort a vector as the system just isn't built for it. The only way you could make such a simple change is in the Simple2DRenderer where we are still storing everything in a bulk manner. The batch renderer just ruins everything by rendering to the buffer on submission (yet again, not saying this is bad but it doesn't help in this scenario). With this suggested method you would just render them all to the buffer after sorting so you still get the benefit of the batching but also the benefits of the sorting.

Breakdown of efficiency improvements (+) and places where efficiency is hurt (-):
+submit now is doing much less (unless creating the struct and storing it in the vector is more costly than writing to the vector).
-flush is doing a lot more than just the draw call to render the buffer.
-sorting the vector will take some time.
-we are now doing all of the batching that was done each submission all in the flush method.
+draw calls (the things that take up the most time) have been drastically reduced and in my opinion should far outweigh the small inefficiencies stated above as they are all things that if they were to bring your engine to it's knees show a larger underlying problem.

I hope I was able to help.

from sparky.

Because 2D rendering doesn't define a canonical order (and, typically, requires fairly complex, order dependent alpha compositing), BatchRenderer provides a strict ordering guarantee in the form of submission order. The system is designed to perform well, even given that the input data isn't going to be optimal.

from sparky.