Gluon/Graphics
< Gluon
Tasks
- Implement Animated Sprites properly
- Animated sprites were never really implemented properly, the current approach is pretty hacky. Most of it should be implemented as a Texture subclass, something that is now possible thanks to the refactor. Animated sprites should become an asset type that contain the frame definitions, which would also make it possible to The most prominent issue is how to handle state for individual sprite renderer components such that each individual animated sprite has its own "current frame".
Ideas
- Batching by material and instance
- Currently, sprites are rendered one-by-one, back to front. This is inefficient due to many state changes and hampers perfomance.
- One idea is to change the API so it becomes a bit more flexible. World::render is split into World::startRendering and World::endRendering and GluonEngine::Game::painted() signal is split into beginDraw() endDraw() (or similar). Each draw iteration from the main loop, World::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, World::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.- This was implemented as part of the RenderChain concept during the recent Graphics overhaul.