If I do add a deconstructor which I did that calls glDeleteBuffers on the VBO, would it just make returning a pointer more efficient?
Sure, returning an 8 (or 4) byte value, is slightly more efficient than:
- allocating a new Mesh on the stack
- allocating an array of vertices
- copying in all of the vertices from the mesh being copied
- allocate storage on the GPU for your VBO data
- upload all of your vertices to the GPU
Except..... you're only doing half of the above (which is required if you're going to pass these things around by reference)
I did end up adding a deconstructor and I don't get the VBO drawn on the screen.
Good. Your Mesh class is now releasing the GPU resources when it is called (which is a very good thing)
Also, in your example of the what I should put for the Mesh class and solve the errors I get, why exactly is there an operator =? Wouldn't C++ copy all the variables for me by default if I didn't make a operator=?
It will indeed copy the variables blindy, without any understanding of what those variables mean. Now this is all well and good when you have a simple Vec3 / Matrix. But it's not so good when your class contains a handle to resources allocated on the GPU (i.e. your VBO). If you really think it's a good idea to allow copying of mesh data, you should implement the copy ctor & assignment operators. I'd argue that allowing copying of Mesh data is a bit pointless - it would be far easier to simply draw the same Mesh twice, rather than drawing two meshes that are exactly the same.
Also, whats with the facepalm for using std::vector<Meshes> as a list? Is it supposed to be a pointer to the meshes rather than being on the stack?
They aren't on the stack, they're on the heap, and std::vector is not a list. If it was a list you could get away with it, but not when you're using a std::vector (where push_back may cause the entire array to be reallocated, which would cause all meshes to be reallocated, including all of their vertex arrays, and all GPU resources.