VanillaSnake21 said:
The reason I went with per object approach is because it's so intuitive for me. I define individually what each object will look like by assigning a shader (see my answer above about how I handle shader creation) that will handle that particular look. The way I was thinking about it was like this: a shader is anologous to a material an object is made of and how that material behaves. So it was natural for me to kind of couple that with the actual object. It's a bit more unnatural for me to think of a material as like an effect that I apply first and then pass the objects, and then unapply the effect and render the next batch of objects. I was actually thinking of fixing the redundant states by some simple solution like grouping models by the shaders they use and keeping track if a shader was set already and just not setting it was set previously.
Yes it is no wonder you find it more intuitive that way. I doubt there's anybody who's first approach is not to go “per object”. However the intricacies of the hardware make it more complicated. Per material is the way to go as that is how you can get performance out of your pipeline. For example check out pseudocode for how the Unreal Engine 4.22 rendering does it. The per material strategy works:
foreach( camera )
{
foreach( material )
{
set_shader();
upload_material_parameters()
foreach( instanced_objects with that material )
{
set_mesh();
// already uploaded----upload_object_parameters()
// no need to upload data, just tell gpu to render at some index
render_instanced( instanced_objects.idx, instanced_objects.count )
}
}
}
