A cube or a sphere is a mesh, but are lines and circles?
I'm currently creating a renderer responsible for drawing many different types of object. functions in a namespace called MeshDescription are responsible for running and returning mesh objects so you can do things like this:
Mesh mesh = MeshDescription::Cube();
but I'm wondering if functions for lines and circles should be categorised differently? with a view to changing this soon so that everything is instanced.
A mesh will usually fall into one of the 3 following categories:
At it's core, a mesh is just a collection of vertices, edges, and faces.
If you want to import an object I would separate it's identity from it's mesh. So if you import a plane into the game, I would have some object called "GameEntity" which is a class that has a property of type mesh. The mesh is nothing more than the collection of vertices, uv coords, and other mesh specific properties.
If you want to procedurally generate a terrain, I would have an object called "Terrain" that inherits from "GameEntity". This would already have the mesh property from it's parent class. Again, you are separating what the object does from it's mesh representation.
Lastly if you have primitives, I would have stored representations of each object which would include it's mesh, but also all of it's identifying information like name etc. So this would fall under the "GameEntity" class as well.
Long story short: in your example you are defining cube as a subobject of mesh. Instead I would define everything under a master object class called "GameEntity" which can include a mesh component. Do remember if you implement this that not all "GameEntity" objects must have a mesh. Especially if you had objects like "Camera" inherit from "GameEntity"
I have "Game Engine Architecture" by Jason Gregory. It's a pretty decent overview of the components needed for a game engine. It has a whole section on the rendering engine, but knowing that there are dependencies on the objects you design for rendering is pretty important so you can extend your codebase later.
This is highly subjective; so this is clearly my opinion.
Perfect grammatical code should never be your first priority - discoverability and consistency is. Once a developer knows the 'go to' place for shapes (as a broad term) they typically won't look somewhere else; and will re-implement it.
Don't classify your objects based on their exact category; rather their function. You could do something like:
Mesh mesh = MeshDescription::TwoDimensional::Line();
Mesh mesh = MeshDescription::ThreeDimensional::Cube();
Which retains the common entry-point, the discoverability and the consistency.