Layer support in renderer

[heinezen]

Adds support for multi-mesh objects in the level 2 renderer as well as sorting by layers.

Terrain rendering

• Gamestate
  • Create example terrain layouts
  • New test terrain asset
• Renderer
  • Split terrain chunk into multiple meshes
  • Render meshes individually

Layer support

• Sort animation layer definitions by layer position when loading assets
• Split animation layers into multiple meshes
• Render meshes individually
• Sort renderables by layer position in render pass

[heinezen]

@TheJJ There might be a better approach to do layer support, so your input would be nice to have. In this PR, I added layer suppport into the level 1 renderer (in RenderPass), but there might be a case for moving it to the level 2 renderer.

Here are some advantages/disadvantages I see with each approach:

Layer support in Level 1 (this PR)

• Easy to use (sorting into layers works automatically)
• Layer support is available for all render passes by default (however, only world and terrain stages in level 2 use layers)
• Introduces some complexity and overhead that might slow down rendering pipeline
  • more if statements to check for various things
  • overhead for keeping renderables sorted

Layer support in Level 2

We could do this by emulating each layer with an individual render pass per layer. These passes would all target the same framebuffer.

• Less complexity in level 1
• Maybe code duplication because layers would have to be managed by each render stage
• We have to avoid binding the framebuffer too often because this operation is super expensive

[BluntSlapp]

LG2M

[TheJJ]

awesome!

[TheJJ]

let's use this working approach for now, but some thoughts on the alternative:

having this approach now certailiny works, and we can optimize it further.
i think the more logical approach would be to have something layer-like in both renderer levels.

since the only real layer users are objects (town center e.g.) and the terrain, they can do multiple layer1-passes to draw their layers. to reduce the code duplication when we use layer2-managed render passes, some minimal support (or "optional" activation of it) in layer1 could then be used by layer2 code.

to bind the framebuffer too often, the resulting layer1 instructions somehow have to be batched. which was our long-term idea anyway. so we submit everything (and have it i memory, yes, maybe one chunk after the other?) and optimize and order it, then draw it to the framebuffer with minimal binding switches (also for textures, shaders, ...).

nevertheless as a first step this is approach is good, and as we progress we'll see what we can keep as generalization in layer1 and what should move to layer2, then well converge to the best™ solution i hope :)