An Index Buffer? I'm lost.
Author
Okay, I know that by using a vertex buffer, I can cut down on the amount of shared verticies (I think). ie, turning a square into 4 verticies instaed of 6.
So what does an index buffer do then?
You''re getitng them confused.
Think of a cube, there''s 6 sides of 2 triangles each. If you do the math on that, that makes 36 vertices to define the cube.
BUT, as you can probably see, you can easily define the same cube by using only 8 vertices, one for each corner...
An index buffer will store the offsets (or INDEX) of the vertices in the vertex buffer. It''s generally faster for static VB''s. They aren''t without flaws though, consider the case of this cube, a given corner vertex will feature on 3 sides of the cube - so what happens when you want to specify texture co-ords to allow the cube to have a texture displaying on each face.
One set of tex-coords would be u/v 0,0. Another would be 1,0 - yet another for a different face using the same vertex could be 0,1 - do you see the problem?
So it''s a tradeoff you have to make.
Think of a cube, there''s 6 sides of 2 triangles each. If you do the math on that, that makes 36 vertices to define the cube.
BUT, as you can probably see, you can easily define the same cube by using only 8 vertices, one for each corner...
An index buffer will store the offsets (or INDEX) of the vertices in the vertex buffer. It''s generally faster for static VB''s. They aren''t without flaws though, consider the case of this cube, a given corner vertex will feature on 3 sides of the cube - so what happens when you want to specify texture co-ords to allow the cube to have a texture displaying on each face.
One set of tex-coords would be u/v 0,0. Another would be 1,0 - yet another for a different face using the same vertex could be 0,1 - do you see the problem?
So it''s a tradeoff you have to make.
The vertex buffer just stores the vertices (position, normal,...).
Now, when drawing indexed primitives, the index tells what vertex to take from the vertex buffer.
So, indexed primitives actually cut down the number of vertices to pass.
Now, when drawing indexed primitives, the index tells what vertex to take from the vertex buffer.
So, indexed primitives actually cut down the number of vertices to pass.
An index buffer is used when you''re using indexed primitives (makes sense right! 
)
Say you have a vertex buffer with
1, 1, 0
-1, 1, 0
-1, -1, 0
1, -1, 0
Then you would have an index buffer with (forgive me if they aren''t in technically correct order... this is just an example)
0, 1, 2
0, 1, 3
and you use drawIndexedPrimitive call with that index buffer.
It''s a way to draw primitives that can''t (or aren''t) be easily divided into srips or fans, but still save on performance. In some articles on directX it actually recommends that you use indexed primitive lists over strips or fans.
Hope this helps, and of course, for more info, go to the directx page on the msdn.
)Say you have a vertex buffer with
1, 1, 0
-1, 1, 0
-1, -1, 0
1, -1, 0
Then you would have an index buffer with (forgive me if they aren''t in technically correct order... this is just an example)
0, 1, 2
0, 1, 3
and you use drawIndexedPrimitive call with that index buffer.
It''s a way to draw primitives that can''t (or aren''t) be easily divided into srips or fans, but still save on performance. In some articles on directX it actually recommends that you use indexed primitive lists over strips or fans.
Hope this helps, and of course, for more info, go to the directx page on the msdn.
Index buffers also save you time when you want to add/remove certain vertices from the scene. Say you have a tiled ground with 9 tiles, but 5 of them are of 1 texture and the other 4 are of a different texture. Instead of re-creating the vertex buffer each time, you can just index the vertices from the vertex buffer.
For one thing, you only have to change a few WORDs(16 bit depth) or DWORDs(32 bit depth) that contain the indices, instead of creating a whole new vertex structure and copying it to memory. So, you save on memory and CPU cycles. You can just overwrite the previous DrawIndexedPrimitive indices with the current indices, and change the number of indices to draw.
Be careful though, DirectX will still commit a world transform on the ENTIRE vertex buffer, regardless of which vertices you''re using. So if you create a HUGE vertex buffer, you may not even get a benefit in the end using index buffers. That''s your call though.
Also, as downgraded pointed out, be careful with textures. If you have a mesh that has a single texture that will cover the entire mesh, it''s okay and good to use index buffers. If you have a 9 tile floor, it''s okay but you have to specify texture coords greater than 1 with wrapping enabled as you go down and to the right (in a 2D sense) with each tile. For instance, the top left corner of a texture is 0 and the bottom right is 1. You can, I think your video card has to support it and there is a limit, also call the top left corner 1 and the bottom left corner 2, etc. It''s not possible with a cube because it is closed and the vertices meet up again eventually where they started, causing a paradox of some sorts.
Chris
For one thing, you only have to change a few WORDs(16 bit depth) or DWORDs(32 bit depth) that contain the indices, instead of creating a whole new vertex structure and copying it to memory. So, you save on memory and CPU cycles. You can just overwrite the previous DrawIndexedPrimitive indices with the current indices, and change the number of indices to draw.
Be careful though, DirectX will still commit a world transform on the ENTIRE vertex buffer, regardless of which vertices you''re using. So if you create a HUGE vertex buffer, you may not even get a benefit in the end using index buffers. That''s your call though.
Also, as downgraded pointed out, be careful with textures. If you have a mesh that has a single texture that will cover the entire mesh, it''s okay and good to use index buffers. If you have a 9 tile floor, it''s okay but you have to specify texture coords greater than 1 with wrapping enabled as you go down and to the right (in a 2D sense) with each tile. For instance, the top left corner of a texture is 0 and the bottom right is 1. You can, I think your video card has to support it and there is a limit, also call the top left corner 1 and the bottom left corner 2, etc. It''s not possible with a cube because it is closed and the vertices meet up again eventually where they started, causing a paradox of some sorts.
Chris
hmm....are you sure, that Dx always transforms the whole vb? IMO it''s only doing this with a SVP and not with a HWVP Device.
But you should ensure, that your IB only uses indices, that a not widely distributed in your buffer, but located near to each other to avoid cache misses. I''m not familiar with OpenGL, but it will suffer from the same problem here, I think.
But you should ensure, that your IB only uses indices, that a not widely distributed in your buffer, but located near to each other to avoid cache misses. I''m not familiar with OpenGL, but it will suffer from the same problem here, I think.
I''d bloody hope not!
DirectX just transforms the verts in the order it gets them from the index buffer, or it just transforms the number of verts you supply to DrawPrimitive.
DirectX just transforms the verts in the order it gets them from the index buffer, or it just transforms the number of verts you supply to DrawPrimitive.
quote:Original post by Anonymous Poster
hmm....are you sure, that Dx always transforms the whole vb? IMO it's only doing this with a SVP and not with a HWVP Device.
But you should ensure, that your IB only uses indices, that a not widely distributed in your buffer, but located near to each other to avoid cache misses. I'm not familiar with OpenGL, but it will suffer from the same problem here, I think.
It is possibly in the DX help, or else on the pages of robert dunlop. If you use software vertexprocessing DX transforms the whole vertexbuffer between start vertex and last vertex. If you have one of 1000 vertices and you draw a quad using an index buffer using vertices 0,1,500,900 then it will transform 901 vertices for that.
I have edited my post, I got them mixed up, and anonymous poster was right, sorry.
[edited by - Fidelio66 on January 26, 2004 2:01:20 PM]
hmm...well, I thought a little bit about it and I#m quite sure, that it is the way I said. If the HW would transform all of the vertices, where does it store the transformed vertices? (remember, you can''t get transformed vertices back from Dx/OGL when transformed in HW, so its probably not the GPU ram) and what do you have a vertex cache for (about 12-36 verts or so, but not nearly enough to store a whole vb)?
With a software device (tnl, rasterizer could be in HW) you doesn''t have a vertex cache, so you transform all of them, save them to your ram and the take those you need.
With a software device (tnl, rasterizer could be in HW) you doesn''t have a vertex cache, so you transform all of them, save them to your ram and the take those you need.
Estauns-
Edit: My ascii art stuffed up, will do it again later.
[edited by - Doolwind on January 26, 2004 8:15:40 AM]
Edit: My ascii art stuffed up, will do it again later.
[edited by - Doolwind on January 26, 2004 8:15:40 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
