Jump to content

  • Log In with Google      Sign In   
  • Create Account


Use of Index Buffer Objects with models


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 sublixt   Members   -  Reputation: 103

Like
0Likes
Like

Posted 22 May 2012 - 08:13 PM

I was wondering what is the advantage of using a Vertex Buffer Object with Index Buffer Object in OpenGL in respect to rendering models. From the way I've done it, more memory is being used because with the .obj file format has vertices, vertex normals, and vertex textures all split up then brought togethor in faces. The way I do VBO and IBO I use the glVertexAttribPointer function and define offsets for the vertex, vertex normal, and vertex texture which is not the way that the .obj file seperates its data. This, for me, makes the VBO IBO pair less efficient that just using a VBO. Is this the only way to do it or is there another way to use an IBO to make it act more in the way an obj file works?
P.S. sorry if my wording is bad I'm still learning OpenGL and I don't know the terminology very well.

Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 6685

Like
0Likes
Like

Posted 23 May 2012 - 02:27 AM

First off, .obj files should have nothing to do with the way you render your models. Normaly you import your mesh data in whatever format you like and convert them to a data structure which fits your rendering requirements best.

VBO and IBO are just ways to push your vertex and triangle (indicies) data on the GPU for faster rendering.

#3 mhagain   Crossbones+   -  Reputation: 7422

Like
0Likes
Like

Posted 23 May 2012 - 03:38 AM

You're making the classic mistake of assuming that memory usage is the primary, or even a significant, indicator of performance; understandable enough because it's something that's directly measurable.

That's not the case at all.

The primary bottleneck when transforming vertexes is - guess what? - transforming vertexes, so it follows that the less of them you have to transform the faster you'll run. Other bottlenecks include the amount of data you need to send from system memory to GPU memory and the number of draw-calls you need to make.

This is where index buffers come in.

Using an index buffer will allow you to be able to remove duplicate vertexes from your object. For 3D hardware a "vertex" here is defined as a completely-specified vertex, including position, normal, texcoords, whatever. A single index is a max of 4 bytes so you're clearly looking to get a tradeoff here where the overhead of extra indexes is lower than the size of the vertexes removed. Even if you don't come out on the right side of that tradeoff (which is unlikely but possible with some meshes) another big advantage is that you can use indexes to concatenate multiple different primitives together. If you're currently drawing a model as a succession of multiple GL_TRIANGLE_STRIP/GL_TRIANGLE_FAN calls then switching to indexing will allow you to draw the entire thing with a single GL_TRIANGLES call, which can translate into large savings.

This has basically been the way things have worked since at least sometime in 1999 - Quake III particularly pushed indexed drawing as the path to optimize for - so it's a well-established pattern that you really don't need to worry about.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 sublixt   Members   -  Reputation: 103

Like
0Likes
Like

Posted 23 May 2012 - 08:15 AM

Ok thanks. This really helped me. I'm also glad that I'm just overthinking it instead of making some huge mistake that will take me another week to learn how to fix it.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS