Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualRobTheBloke

Posted 15 March 2013 - 06:31 AM

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.


#1RobTheBloke

Posted 15 March 2013 - 06:21 AM

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.


PARTNERS