Gluon/Graphics

Improving Rendering

Currently, sprites are rendered one-by-one, in a random order. This is inefficient due to many state changes and, due to z-buffer checking, sometimes breaks transparency.

Batching by material and instance

One idea is to change the API so it becomes a bit more flexible. Engine::render is split into Engine::startRendering and Engine::endRendering and GluonEngine::Game::painted() signal is split into beginDraw() endDraw() (or similar). Each draw iteration from the main loop, Engine::startRendering is called due to being connected to Game::beginDraw. This method does the setup that's necessary to properly start rendering, such as binding all needed RenderTargets. After that, the actual draw iteration is performed and all objects are iterated over. Each component is required to call item->render() if it wants to render anything this frame. However, instead of directly rendering the item, the item is added to the list of items to be rendered.

Once the main iteration is done, Engine::endRendering() is called due to being connected to Game::endDraw(). This call then processes the list of items scheduled to be rendered. The items in this list are first put in to groups separated by material. These groups are then separated by material instance. Finally, each subgroup is split into further subgroups based on a maximum number of items per group. Once this sorting has been done, each group is rendered completely, minimising the amount of state changes between rendering.

However, this does not necessarily fix z-sorting and transparency. Maybe we should group by z-integer first? But this does not scale to (semi) 3d rendering.

Copy-on-write material instances

As discussed with leinir, the current material instance concept is not entirely perfect yet. The instance properties should be displayed in the property view of the object using the instance. Furthermore, there should be some copy-on-write semantics.

Per-RenderTarget active camera

It should be possible for each RenderTarget to set its own active camera. This would enable things like rendering an overview map, or rendering character portraits.