OpenGL Wrapper
Posted: Tue Aug 23, 2011 8:27 pm
Hey again (I believe the "Wolf" in my name gives away who I am).
Well, I finally started to think about an actual implementation.
I'll leave shaders for later on, since I want to have actual data to test first, so buffers it is.
What I thought so far was something along the lines of having a VertexAttribute class with a name and size.
Each Buffer class instance will hold the buffer handle itself, the array data (to make it easy to edit stuff later on and call an update() method or something like that), an array of VertexAttribute instances if they exist (which they don't for index buffers), and some flags saying what data types this buffer holds (the buffer type, ARRAY_BUFFER or ELEMENT_ARRAY_BUFFER, and the data type which so far is only FLOAT or UNSIGNED_INT, I'll bother later on to make the types smaller if appropriate).
Now, I am not really sure what to do when binding - the buffers can be represented in many different ways (interleaved and non-interleaved data in many orders).
Should the client give this information, which would mean it's basically not saving his effort at all (since he is giving all the information you usually give anyway), or should I make a default way and force the client to use a specific format?
I am also not a big fan of calling manually render/draw methods. Do you have any thoughts of making an internal list of all models that need to be rendered with some sort of register/unregister mechanism?
My main issue when thinking about my data specifically, is that my main level data is a huge 2D grid of uniform-sized tiles (all of them have the same width and the same height). I don't know too much about face culling, but with only basic information, I can instantly drop out every single tile that isn't visible.
How would I pass the information needed (the level size, size of the tiles, the location of the "camera", and the resolution of the view) in a general way?
I am also wondering what's the most optimized way to render the above level data. Currently I hold one buffer, and draw each visible tile in turn with a new drawArrays() call, while binding its texture.
This is obviously not very optimized.
It's obvious to me that I should sort by texture first of all (and make the binding function only bind a texture if it isn't bound already obviously, it seemed to bug last time I tried it though, I am using WebGL), but would that be worth sorting perhaps a few hundred tiles?
And then of course I can optimize it more to sort only if a new line/row of tiles is visible, meaning you moved enough that it's worth to sort again.
I am also wondering if using a flat index buffer would be faster, simply because it sends less data - 4 bytes instead of 20 for each vertex.
And then there are thoughts about updating the index buffer itself together with the sorting, so that I would be able to call drawElements N times as the number of visible textures, rather then the number of visible tiles.
But yeah, I guess getting a nice looking and easy to use API is more important to me right now then to get it to work as fast as possible.
The current code can render a few hundred tiles with not much of a problem even when binding a texture for each and each of them.
Well, I finally started to think about an actual implementation.
I'll leave shaders for later on, since I want to have actual data to test first, so buffers it is.
What I thought so far was something along the lines of having a VertexAttribute class with a name and size.
Each Buffer class instance will hold the buffer handle itself, the array data (to make it easy to edit stuff later on and call an update() method or something like that), an array of VertexAttribute instances if they exist (which they don't for index buffers), and some flags saying what data types this buffer holds (the buffer type, ARRAY_BUFFER or ELEMENT_ARRAY_BUFFER, and the data type which so far is only FLOAT or UNSIGNED_INT, I'll bother later on to make the types smaller if appropriate).
Now, I am not really sure what to do when binding - the buffers can be represented in many different ways (interleaved and non-interleaved data in many orders).
Should the client give this information, which would mean it's basically not saving his effort at all (since he is giving all the information you usually give anyway), or should I make a default way and force the client to use a specific format?
I am also not a big fan of calling manually render/draw methods. Do you have any thoughts of making an internal list of all models that need to be rendered with some sort of register/unregister mechanism?
My main issue when thinking about my data specifically, is that my main level data is a huge 2D grid of uniform-sized tiles (all of them have the same width and the same height). I don't know too much about face culling, but with only basic information, I can instantly drop out every single tile that isn't visible.
How would I pass the information needed (the level size, size of the tiles, the location of the "camera", and the resolution of the view) in a general way?
I am also wondering what's the most optimized way to render the above level data. Currently I hold one buffer, and draw each visible tile in turn with a new drawArrays() call, while binding its texture.
This is obviously not very optimized.
It's obvious to me that I should sort by texture first of all (and make the binding function only bind a texture if it isn't bound already obviously, it seemed to bug last time I tried it though, I am using WebGL), but would that be worth sorting perhaps a few hundred tiles?
And then of course I can optimize it more to sort only if a new line/row of tiles is visible, meaning you moved enough that it's worth to sort again.
I am also wondering if using a flat index buffer would be faster, simply because it sends less data - 4 bytes instead of 20 for each vertex.
And then there are thoughts about updating the index buffer itself together with the sorting, so that I would be able to call drawElements N times as the number of visible textures, rather then the number of visible tiles.
But yeah, I guess getting a nice looking and easy to use API is more important to me right now then to get it to work as fast as possible.
The current code can render a few hundred tiles with not much of a problem even when binding a texture for each and each of them.