hey people of gamedev, i'm working on some ideas, and don't like what i've come up with, so i'd like to hear some other ideas how to approach the problem:

firstly, what i have:
I have a renderobject class, this class stores the type of way to draw an object(triangle, lines, etc), and the vertices that make up the object, as well as a single material which is used to draw the object.

I have a mesh class that can contain multiple renderobjects, and draw's them.

I have a material class, this class can store a color value, and upto 4 textures in 4 "slots", it also can store the shader which should be used to draw the object with this material.

then i have my shader class, which has three callbacks, a set callback, used when a material in the video driver is changed, or the shader is first set, this initialized the shader uniforms, and setups the shader to recieve renderobjects.. a render callback, which takes a renderobject, and appropiatly draws it. and finally, an disable callback, for when the shader is removed from being active.

now then, when i load a model(and let's say it's loaded from a simply .obj file, so it only contains basic material/vertice information). lets say it has a uv texture, and a color for it's material, basically I have to setup the model with a shader, and I have to do this with every object loaded, it can get tedious, and i don't really like the overall design, this method also limits me pretty severly with what i can do with shaders, and it also means that everything has to be a renderobject to be submitted to the shader for drawing.

in short, this system is a pretty big burden on how much i can do with building games, and i'd like a better idea for a simple, and easier implementable system.

In my system Material is the most "intelligent" class. I have the following hierarchy:

1. Vertexbuffer, Indexbuffer - contain all vertices and indices of certain geometry. VB has flexible system of vertex attributes - i.e. there are slots for "normal" attributes like 3D coordinates, normals and UV, but one can add as many extra attributes as needed.
   
2. Mesh - binds together VB, IB and Material(s), also has 3D transformation and bbox assigned to it. Mesh has list of fragments, each fragment can be rendered with different material. ::display() method of mesh submits a renderdata to list for later processing (renderdata has link to VB, IB, transformation and material).
   Multiple meshes may share materials and vertex/index buffers.
   
3. Shader, Program - these are just frontends of OpenGL shader and program objects. ::bind() method of program sets it as active OpneGL program but does not set up uniforms - the latter is left for material.
   
4. Material - the heavy duty class. Material has one or more programs (i.e. shader frontends) (depending on render pass, the same mesh fragment - having same material - may be rendered with different shader). In ::render() method of material the renderdata is parsed, uniforms set up, relevant attributes of associated VB bound and glDrawElements... called.
   Multiple materials may share programs.
   

The idea behind my design is, that all geometry objects have pretty similar structure while the materials vary a lot. Materials have also access to global rendering data (like GBuffer textures etc.). Material also "knows" which attributes associated shader needs and may only bind subset of all attributes in VB - for example in depth pass it can use separate depth shader and ignore normals/uv/colors...