This change refactors how the renderer handles per instance data. Per instance data contains things like the object to world transform, color etc. It is used to render the same mesh in multiple places with one draw call.

Previously the per instance data was collected during the rendering itself. This had a few issues: The renderer had to iterate through all renderdata of a batch and collect the instance data from that and then upload that to the GPU. This was done per submesh and per view, so even for a mesh with just one submesh this could mean that the same data was collected and uploaded like e.g. 3 times per frame (shadow, depth pre pass + main pass).

With this refactoring the instance data is already allocated and filled during the extraction. This means that for static objects it will only be collected and uploaded once and then re-used. Dynamic objects will still fill the data every frame but it is only uploaded once per frame. Furthermore the instance data is not duplicated for submeshes anymore.
Since the data in the gpu buffer can now be in arbitrary order a new indirection vertex buffer is introduced which contains various data offsets:

• instance data offset
• custom instance data offset
• material data offset
• skinning data offset

These offsets are already collected during batching in the extraction phase so that the renderer does not have to look at individual render data anymore but can just operate on batches. It highly depends on the scene but I could measure speedups of 3x in the render thread.

There are some more advantages of this approach:

• Skinned meshes can now be batched as well
• It is now possible to attach custom per instance data to a mesh component. This requires a custom C++ component though. See ezMeshComponentBase::SetCustomInstanceData
• ezRenderData became a lot smaller since it does not need to contain the per instance data as well.
• This is also a preparation for bindless rendering in the future
• With all these refactorings I could remove a lot of custom renderers

Breaking changes:

• The ProcVertexColorComponent does not do rendering by itself anymore but requires a mesh component besides it. It will then use the custom per instance data to inject the per instance vertex colors to the shader. The corresponding shader helper functions have been moved out into its own header file: ProcGen/ProcGenVertexColor.h.
• All custom components that want to render something with ezMeshRenderData need to be adapted to the new system. See ezMeshComponentBase for an example.