Gluon/Graphics: Difference between revisions

← Older edit Newer edit →

Revision as of 15:03, 4 December 2012

Tasks

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.

@@ 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===
+==Ideas==
-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.
+;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.
-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.
-==Copy-on-write material instances==
+;Per-RenderTarget active camera
-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.
+: <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.
-==Per-RenderTarget active camera==
-<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.