Gluon/Graphics: Difference between revisions

From KDE Community Wiki
(Created page with '==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 brea...')
 
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Improving Rendering==
==Tasks==
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===
;Implement Animated Sprites properly
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.
: 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".


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.
==Ideas==


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.
;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==
;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.
: 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==
;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.
: <strike>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.</strike>
: This was implemented as part of the RenderChain concept during the recent Graphics overhaul.

Latest revision as of 16:12, 4 December 2012

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.