1
\$\begingroup\$

I'm making a minecraft style game where each chunk each chunk has buffers holding the position of all visible blocks and texture atlas coordinates of the 36 vertices that are needed to draw the triangles.

I have 8 vertices and an EBO that I use for the triangles so it takes up sizeof(GLfloat)*3*8 + sizeof(GLuint)*36 + sizeof(Glfloat)*2*36 so 528 bytes. that seems like a lot per block meaning that if I am rendering around 16*16 chunks(I use an stl::map not an array) 16*16*256 chunks that have around 300 visible blocks that means I am sending about 40 mb of data to the GPU each frame.

It runs smoothly now but could this end up being a problem? or is there a way to reduce this?

one other thing, I tried to change my program from using gldraw arrays and having 720 bytes for each block to using an EBO for just the position. how can you control what vbo the ebo operates on?

for example the EBO would have indices to the points of the cube and texture coordinates but still have an instance array for the position

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

Since data is only sent to the GPU when you change it on the CPU, you can identify which data does not change every frame and split that out. Positions, for example, are likely fixed at creation time and never really need to change again, so your position data can go into one vertex attribute stream and your texture coordinates (which do change, potentially) into a separate stream.

Then you only update the second stream every frame. Any other varying data goes into that second stream, and any other fixed data goes into the first.

If you have access to them, geometry shaders are another option you can use (possibly in addition to the two streams). Instead of all eight cube positions, you can just store a single position and expand that into the necessary eight (or whatever) vertices in a geometry shader. Likewise for texture coordinates, in fact; you could just store a "texture index" and do some math to adjust the texture coordinates for your generated vertices.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .