I took so long to reply because I wrote a fully detailed post, nearly finished it when a friend came over. As were talking my PC crashed randomly and it took a full day to bring myself to even try again, and it still won’t be as detailed.My implementation involves dynamically combining index buffers and vertex buffers, so that during a normal render vertex buffers A and B are active, and during the creation of a shadow map, only B is active, etc.
Its just hides away the actual renderin from the model-class. It might be obligate, but I'm feeling kinda comfortable with it.. its interesting however that you said its not possible to achieve such things like modern terrains with that. From what I see, both cases are basically the same, just with different implentations. Is there something I oversee? Obviously from what I understand you could do the things you described with both my and your implentation. Well, maybe I am wrong..?
Trying to centralize all the different ways in which things can be drawn will just create a mess.
Sure, a mesh class could allow multiple vertex buffers and allow manual setting of different combinations, but:
#1: Since it is a convenience class, that is no more beneficial than just keeping the various index/vertex buffers and setting them manually, as long as your wrappers for index/vertex buffers are also good.
#2: When do you stop adding features to support various new drawing methods and finally just say, “This is just too messy and bloated and in order to get all this flexibility I have made it either hard to use or generalized so much that all render types work but none are particularly fast.”
The reason you would not want to centralize your drawing code will become more apparent when terrain is discussed.
This is horrible when you are submitting this from your model, the model is now responsible for the way it is drawn which means you can only use a graphics wrapper to render it. You can do no more ordering on these render calls from your model either, say you have a terrain with water on it. You have to render the water last to get the transparency to work properly, you are forcing a dependency in how these two models are now rendering. If they actually give a render instance back that tells the renderer which pieces they would like to use, the renderer then can determine that the transparant items need to be rendered last, but you can submit them to the renderer in any order.
There is a reason why you have your render queue and why a renderer performs sorts on that queue as the renderer knows more about the scene it is about to submit to the actuall device than the scene manager or model need to know.
When you come down to it all the renderer needs to do is set the correct states for rendering, shaders, textures and all that. But the model should not be responisible for making these calls, it should be responsible for telling the renderer how it wants to be rendered but not by setting this on the device.
The renderer is then responsible for going through the renderlists and rendering them correctly.