Optimised binding for mesh render system
Created by: ZilverBlade
currently there are renderForwardOld and renderForwardNew, these work fundamentally different, as renderForwardNew currently has to bind each mesh for the amount of times that mesh has a specific submesh using a material with a certain class.
The old system however only bound the mesh once per frame, while binding the pipeline for each material that is contained in that mesh. It did create the issue where in deferred rendering you cannot defer the transparent materials for later, but that was fixed recently with a sneaky workaround.
The problem is due to renderForwardNew being overengineered, it also requires everything to be rendered explicitly, so the renderer has to be notified if a mesh component has been added, or if a material has been modified.
A large problem with this is that since renderForwardNew also binds a mesh multiple times per frame, the efficiency drastically decreases with a variety of both meshes and materials (e.g. 100 meshes with materials that have their own unique material class (currently 8 class combinations as of version 1.2.8.r7-alpha) can be up to 30% slower or more than binding a mesh once per frame and binding the material pipelines subsequently for each submesh).
There needs to be some sort of solution to either get rid of the mesh binding all together, or a better way of optimising the material render classes, perhaps maybe rebuilding the index buffers for a material rather than a mesh, which instantly provides instanced rendering (in some sort of way, certainly not the best since you are still binding more vertices), but can be ridiculously slow if a material is added to another mesh or if a mesh is removed containing that material (and will exponentially increase with more vertices bound).