Rework the way rendering is structured about wasabi HOT 2 OPEN

Currently render targets (WRenderTarget) created by the user create their own (buffered and fenced) command buffers. This is requiring a vkWaitQueueIdle operation (bad) because the two command buffers are not synchronized and the resources are being used in both. Investigate the possibility of using the same primary command buffer of the renderer? This way, it will be synchronized with the renderer's primary command buffer (i.e. render to secondary first, then render normally, as two consecutive begin/end renderPass in the same command buffer).

Additionally, currently WRenderTargets can only be rendered to if user creates custom WEffects (vulkan pipelines) for that WRenderTarget or the render pass in the WRenderTarget is "compatible" with the renderer's render pass (compatible means its similar in a compatible way, for now, it seems to me that it was to have the same target attachments (1 color 1 depth, with same formats). Investigate possibilities here... Do we need this limitation? can the engine automatically detect incompatible pipelines and fork out resources (and should it? or would that mess the user up...)?

from wasabi.

Implemented WRenderGroup + WRenderable => generic implementable rendering mechanism. Render group should be renamed to WRenderGraph. The goal:

• One WRenderGraph for the renderer
• WRenderGraph will index have all objects, terrains, sprites, particles, etc... (all inherit from WRenderable)
• WRenderGraph will be primarily indexed by WEffect. Each effect will have a priority and WRenderables of an effect will be rendered based on the effect's priority
• A WRenderable also has its own rendering priority to sort within the same effect
• Effects have render flags, this helps more sophisticated renderers (e.g. deferred renderer) to control the rendering (e.g. no 2D in GBuffer, etc...)
  • E.g. a renderer can have multiple stages, each stage will use the WRenderGraph by supplying different render flags

For future:

• WRenderables of the same WEffect that have the same render priority can be somehow grouped together into one (instanced?) draw call automatically. This is a big potential optimization.
  • Can use push constants as well to optimize (if all WRenderables only differ in world matrix, for example). This is a common scenario. How can we optimize so that no unnecessary resources are created, but with minimal user interaction?
• Can specify static objects, and possibly merge geometries of static objects that use the same effect.
  • Maybe it is more optimal that the user specifies this, but perhaps this can create an easier experience if done automatically.
  • How does this impact frustum culling loss? Need to make sure proximity also makes sense...

from wasabi.