Preparing for instanced rendering

[popcron]

• push constant renamed to instance data
• materials/shaders knowing if they're meant for instance rendering or not
• renderer component storing a hash of instance data array
  • this is so that other systems can batch based on mesh+material+instance data array hash
• array element as renderer component

[popcron]

Another thing to keep in mind, some rendering libraries allow batch rendering with instance buffers, while also using push constants. So although the previously named push constants got renamed to instance data, there still needs to be a way to describe both. Both per instance data, and push constants.

Push constants could instead be renamed to just constants. And an additional list of per instance data. Then when a material is being assembled with bindings, constants can be added for things like camera matrices, and then per instance data binding components on the entity being rendered.

[popcron]

i wish i put reasons for why exactly push constants needed to be renamed to instance data. because i remember that i thought it made sense, leading to "instance data" being used for instance rendering, but i dont remember why exactly. in vulkan, push constants can still be used alongside instance data. frankly, the name shouldve stayed the same, and the route to batching shouldve taken the component bindings into account instead.

[popcron]

if there is to be instanced rendering, there has to be input data. if the input data are entities, then this is very flexible and easy to work with. if the input data are array elements, then it can be a bit more performant at the cost of having to copy the data to the array elements. it would be a good idea to support both cases, because as array elements is perfect for particle systems. but as entities is perfect for general use cases, like sprite renderers.

initially the input will be entities, support for array elements will come later, which means for now:

• multiple entities with the same material
  • this material must be able to describe which components are placed where in the ssbo
    • the extra information is called "instance data"

[popcron]

if there is to be instanced rendering, there has to be input data. if the input data are entities, then this is very flexible and easy to work with. if the input data are array elements, then it can be a bit more performant at the cost of having to copy the data to the array elements. it would be a good idea to support both cases, because as array elements is perfect for particle systems. but as entities is perfect for general use cases, like sprite renderers.

initially the input will be entities, support for array elements will come later, which means for now:

• multiple entities with the same material
  • this material must be able to describe which components are placed where in the ssbo
    • the extra information is called "instance data"

Makes sense why I decided to rename them to instance data, because I thought the originally named push constants were describing that. But thats only because of how I was using them as a user of the library, not as a developer of the library. So yeah, push constants are their own thing that will be restored if they aren't already. And instance data or something like it will be added in order to describe elements of many entities in one large ssbo

[popcron]

As mentioned in #9, handling ssbos will come first. And for instanced rendering, there will be an array of instance data that each describe what component is put where. The ssbo on the material will be assembled by a new system. It will find all entities that have the same material, and it will grab the component data based on the instance data array, making it ready for specific rendering systems to use.