Hey all! I've been writing my own game engine, but I have hit a roadblock. I am currently trying to add support for rendering models and other geometry. The renderer currently takes in a Vertex Array Object and a Shader in order to draw. The question I have is should the mesh contain only vertex data (index buffer, etc.) or it should also hold the shader? Possibly the Material class should hold a shader? Should the texture be separate as well? How would a basic renderer handle these things architecturally?

I think you need to make a game in order to realize which is the best decision. Reason about all the data that you need in order get something drawn to the screen, the way you group that data is something arbitrary, but it will determine the simplicity and performance of the rest of the game.

FoolishWasTaken said:
The question I have is should the mesh contain only vertex data (index buffer, etc.) or it should also hold the shader? Possibly the Material class should hold a shader? Should the texture be separate as well? How would a basic renderer handle these things architecturally?

When you don't know the answer to a question, one way to go about it, is to simply try all possible cases. This problem doesn't have too many different things to shuffle, so the number of options is fairly limited.

In theory, you can write an implementation for each case, but a much faster approach can be to visualize the different cases on sheets of paper for yourself. Eg draw a box for each class that you have, and add names in the box for data that's inside.

Next, ask yourself, what are reasonable things that a user wants? Eg swap a texture. (No idea really, I just picked one, you can probably make a list of things that should be feasible for a user.)

Then take a sheet with one possible solution in class boxes. How easy is it to achieve the things the user wants given the solution? Do that for all solutions, and you can get a good idea of the strong and weak points of each solution, thus guiding you towards the solution.

@Alberth So pretty much create a UML diagram with a couple of scenarios. I never thought about the “being able to replace” certain components at runtime. This is indeed interesting and I will look into it. Thank you!

FoolishWasTaken said:
I never thought about the “being able to replace” certain components at runtime.

Maybe your starting point was wrong. Reading it again, you seem mostly worried about code/class structure. This is quite normal for us, techies, we worry a lot about such things. However, user needs and requirements are usually leading (software has to work for the user, whoever he/she is, including yourself). Code/class structure must fit those needs, and thus the software design has constraints from the user. Only when you're “far enough” away from the user, the technical design considerations come into play.

Of course, with software being extremely flexible, you still have a lot of room (or can make a lot of room) to create a design.

FoolishWasTaken said:
So pretty much create a UML diagram

I was thinking one diagram for each solution, but if one diagram for all works for you, that's fine too ?