Do you still consider my design wrong?
I do. You were more careful about not using the terms “mesh” and “model” interchangeably, and while your mesh class has no collision data etc., it is still not really a useful class to even have at all.
Mainly your post has made it apparent that you really don’t know the full scope of 3D programming, which is fine. It is a huge subject and it takes many years to learn, and the only way to get there is to try, try, and try again, as long as each time you fail you see why you could have done better.
The first thing that gives me that feeling is that you have a mesh class at all. I will explain why shortly.
The second is that you suggested using a mesh for terrain.
Terrain is not a mesh. A mesh could be suitable for a small area of terrain, but in any area of usefulness terrain is a very specific method of combining index buffers, vertex buffers, shaders, and textures such that detail decreases in the distance. It is a type of renderable object that uses constant modification/swapping of parts/LOD changes in order to maintain a reasonable level of performance. It often requires streaming data and updating in real-time.
A mesh can’t do that (practically).
This is one example of special ways things draw themselves, and there are many more. Which is why a mesh class is useless.
I couldn’t even use one for my own model class. I keep my vertex buffer broken into multiple streams to avoid sending useless data during shadow-map generation. They all share the same index buffer. Sometimes some vertex buffers are enabled and sometimes others are.
A mesh class is restrictive. You will never be able to handle all the cases for ways in which things want to draw themselves, so it is hopeless to even try.
As I said before, the only things a graphics module needs to provide are vertex buffers, index buffers, textures, shaders, and a few helper functions such as a render queue. No meshes.
This eliminates the need for any factories as well.
You put a lot of emphasis on keeping things easy to use. Again, this is fine, but it is in the wrong place.
A mesh class may be use to use, but it is restrictive as can be. With today’s demands on graphics, you simply can’t find a use for such a class. New techniques require all kinds of different combinations of vertex buffers etc.
The graphics library only needs to provide the components. The vertex buffers themselves, not a mesh simplifier.
Move the simplification over to the actual models. And I am talking about the objects that contain physics information as well as a graphics data.
A shared model, or master model, is loaded only once. Instances are spawned from it, sharing its graphics data. And the simplification for drawing models happens inside the model class.
You say it is simple to call Graphics::DrawMesh().
I think it is simple to call Model::Draw().
You say it is simple to call Graphics::DrawWorld().
I think it is simple to call SceneManager::Draw().
The point is all the same simplifications are there, just moved around.
Your graphics engine is doing too much.
L. Spiro