• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
SFCBias

Index Buffer Object vs. Index Array

9 posts in this topic

After writing some code to load a 3ds mesh (using lib3ds) I found that rendering using indices caused problems, at least for me. After storing all the vertex data into one array. I divide each lib3dsMesh into my own Submesh subclass which stores index data.

 

My question is what are (if any) the performance differences in storing index data in an array and using it to call glDrawElements:


 

GLuint* indices;
void draw()
{
   ...
  glDrawElements(GL_TRIANGLES, submesh.i_data.size(), GL_UNSIGNED_SHORT, &indices[0]);
  ...
}
 

 

And using a BufferObject to store them

 

GLuint* indices;
...Fill array...

void build()
{
    glGenBuffers(1,&ibo);
    ...Fill buffer...
}

void draw()
{
  glBindBuffer(GL_ELEMENT_ARRAY,...);
   ...
  glDrawElements(GL_TRIANGLES, submesh.i_data.size(), GL_UNSIGNED_SHORT, <submesh offset>);
  ...
}

 

 

 

0

Share this post


Link to post
Share on other sites

You use the Index buffer that way not only you save memory on reusing vertices. You can also used index buffers as a way to split the mesh by material id, that way If you have a mesh that uses multiple material, you can break each section into his own index buffer while referencing the same vertex buffer. For example let's say you wanted to draw an Quad, you would basically need 6 vertices. But with an index buffer you only need 4 vertices and the index buffer would reference which  one of those vertices it needs to use to create the quad.

Edited by BornToCode
1

Share this post


Link to post
Share on other sites

You use the Index buffer that way not only you save memory on reusing vertices. You can also used index buffers as a way to split the mesh by material id, that way If you have a mesh that uses multiple material, you can break each section into his own index buffer while referencing the same vertex buffer. For example let's say you wanted to draw an Quad, you would basically need 6 vertices. But with an index buffer you only need 4 vertices and the index buffer would reference which  one of those vertices it needs to use to create the quad.

 

Wut? Whether the index data is stored in a vertex buffer, or whether it's stored in an array in system memory, they'll both consume exactly the same amount of memory.

 

My question is what are (if any) the performance differences in storing index data in an array and using it to call glDrawElements:

The Buffer version *should* be quicker (unless you are using an integrated graphics card that makes use of system memory instead of its own dedicated GDDR5 ram. In general, prefer vertex buffer objects, to the older vertex array approach.

2

Share this post


Link to post
Share on other sites

You use the Index buffer that way not only you save memory on reusing vertices. You can also used index buffers as a way to split the mesh by material id, that way If you have a mesh that uses multiple material, you can break each section into his own index buffer while referencing the same vertex buffer. For example let's say you wanted to draw an Quad, you would basically need 6 vertices. But with an index buffer you only need 4 vertices and the index buffer would reference which  one of those vertices it needs to use to create the quad.

 

Wut? Whether the index data is stored in a vertex buffer, or whether it's stored in an array in system memory, they'll both consume exactly the same amount of memory.

 

 

>>>My question is what are (if any) the performance differences in storing index data in an array and using it to call glDrawElements:

The Buffer version *should* be quicker (unless you are using an integrated graphics card that makes use of system memory instead of its own dedicated GDDR5 ram. In general, prefer vertex buffer objects, to the older vertex array approach.

 

I think you are confuse, the OP is not asking if he is storing the index into the vertex buffer. He is talking about splitting his mesh into Submeshes.

Edited by BornToCode
0

Share this post


Link to post
Share on other sites

Just use buffer objects, it's the right way nowadays.

 

I think you are confuse, the OP is not asking if he is storing the index into the vertex buffer. He is talking about splitting his mesh into Submeshes.

 

OP didn't ask anything about _not_ using indices. He wanted to know the difference in those two examples he gave, that reads in the topic. The first one has it's data saved on the system memory and the second one has it on the GPU. They'll both consume the same amount of memory, just like RobTheBloke said.

1

Share this post


Link to post
Share on other sites

I think you are confuse, the OP is not asking if he is storing the index into the vertex buffer. He is talking about splitting his mesh into Submeshes.

 

Read the question again: the OP is talking about indexed drawing in both cases (notice the glDrawElements call in both).  In case 1 he's got the index data in system memory, in case 2 he's got it in a buffer object.  He does mention separate meshes for sure, but focus on the bit beginning with "my question is", which is nothing to do with separate meshes.

1

Share this post


Link to post
Share on other sites

There can be a substantial improvement when implementing glDrawElements vs. glDrawArrays, but not in all cases. If you have a lot of non-contiguous mesh then there may actually be a performance hit. Particles, for instance. There has to be lots of duplicate vertices for the index tracking method to improve performance because there is additional calculation overhead. I'm not sure that the extra memory used is much of a problem these days since fast, cheap ram is standard issue now. What 'BornToCode' said about using indices to break up multi-component models into pieces is something to consider, however if you do this, pay close attention to getting the index count perfect or you will likely see horrible crashes. There is a document called 'OpenGL ES Programming Guide for iOS' that has some advice on this matter. http://developer.apple.com/library/ios/#documentation/3ddrawing/conceptual/opengles_programmingguide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html Here's an nVdia document with many ideas for optimizations. http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html Remember that their are now half a dozen excellent GPU companies and they all have different ways of doing things under the hood, even though the interfaces are mostly the same. What works best on one may not work best on all of them. That Apple document suggests that you try both ways and see what works best for your situation.

1

Share this post


Link to post
Share on other sites

Sponji and mhagain are right, that was my question and thank you for your answers. As well as marcClintDion, thank you for your descriptive answer, and references(!). 

This was more of a simply a conceptual question since I noticed it could work both ways.

0

Share this post


Link to post
Share on other sites

One thing worth noting about indexed rendering.  As well as saving memory from eliminating duplicate verts (not that important as memory is no longer a scarce resource for many use cases) and as well as saving VS transforms from being able to reuse the results of previous ones for duplicate verts (very important) indices also allow you to concatenate multiple primitives together to a single draw call.

 

Let's take that particle system example mentioned upthread.  In the old days when you had the GL_QUADS primitive type this wasn't a big deal; with GL_QUADS deprecated in recent GL_VERSIONs (or not present at all in ES) a particle system may be exactly where you need indices the most.  Represent each particle as a tristrip, and use indices to join them all in a single GL_TRIANGLES call, and you can get much greater efficiency than using degenerate triangles (an index will always be smaller than a vertex, and the 6 indices needed to join strips this way are much smaller than the extra verts needed).

 

Of course, there are other solutions available to this problem too (e.g. point sprites, instancing, geometry shaders, primitive restart) but they're not always available (particularly if we're thinking ES) and each has their own particular quirks.  Using indices is the most robust general-case solution.

 

With specific relevance to meshes, one case where indices helps is with a mesh composed of multiple strips and fans.  Indices are a great way of joining all those strips and fans together and being able to handle the entire mesh in a single draw call; you may not get much vertex reuse, and you may get extra memory usage, but that single draw call versus 10s, 100s or even 1000s of draw calls should more than offset things and give you faster overall performance on balance.

 

As always - profile and determine which is best for your own use case, but be aware that there is more to indices than just saving memory or reusing duplicate verts - even if neither of those two apply, you may still gain advantages from them.

Edited by mhagain
0

Share this post


Link to post
Share on other sites

I clearly need to pay more attention to what I'm reading, I thought you were asking about whether or not to use indices, when really you were asking about whether or not you should store them in system memory or video memory. Silly. Anyways, on the this document http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html it says under the heading "28.3.3 Optimizing Vertex Processing" that for some cache optimizations to take place, you have to use indexed geometry. I suspect that you'd have to use an index buffer for this to work but I'm guessing at this, I'm assuming that you have to explicitely send the index to the GPU for it to be aware of the index. The following document seems to hint at this, under the heading "Take full advantage of Tegra’s sophisticated post-transform cache by following these guidelines:" http://docs.nvidia.com/tegra/data/Optimize_OpenGL_ES_2_0_Performance_for_Tegra.html I think that what they are saying is: If the GPU does not have a copy of the index then the values calculated for the first vertex cannot be cached and reused for redundant vertices so the vertex processor has to now run again and again needlessly for overlapping points.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0