• Advertisement
Sign in to follow this  

Index Buffers

This topic is 4328 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm creating a terrain engine with support for textures nothing special. I started off using TriangleStrips without IndexBuffers and that worked fine, but for performance reasons I would like to use Index Buffers... so I started to write some code... but halfway I got confused.... The Indexes in a Index Buffer refer to a Vertex in a VertexBuffer, this is easy because that way vertexes that are positioned on the same place only have to be loaded into the memory once. Right? If the vertex only contains a position this should work fine, but my vertex also contains uv-mapping coords and blending values... and these aren't equal for verteces positioned on the same place... I hope you guys understand my problem... Is there a solution for this? Or is it not possible using Index Buffers when Vertexes positioned on the same place have diferent uv-mapping coords? Maybe I'm totally wrong about this but any help is appreciated, Quinnie

Share this post


Link to post
Share on other sites
Advertisement
Quote:
The Indexes in a Index Buffer refer to a Vertex in a VertexBuffer, this is easy because that way vertexes that are positioned on the same place only have to be loaded into the memory once. Right?
Yes, pretty much. You can also potentially gain some optimization by having better pre/post transform cache usage.

Quote:
my vertex also contains uv-mapping coords and blending values... and these aren't equal for verteces positioned on the same place... I hope you guys understand my problem...
Fairly classic problem unfortunately. Same thing happens for a trivial cube - 8 vertices and 36 indices won't work if you want correct lighting...

There isn't really any way around it. You need to design your vertex layout so triangles can share the same texture coordinates (+normals etc..)

hth
Jack

Share this post


Link to post
Share on other sites
Quote:

There isn't really any way around it. You need to design your vertex layout so triangles can share the same texture coordinates (+ normals etc..)


So that means forget Index Buffering?

Also I was interested in using Pixel Shaders for the multitexturing used by the terrain engine. I didn't started to implement this yet though so I don't have much knowledge of it yet, but when using Pixel Shaders would it be possible to set the uv mapping without implementing them into the vertexbuffer?

Maybe this idea is totaly crazy but I was just wondering...

Share this post


Link to post
Share on other sites
Quote:
Original post by Quinnie
Quote:

There isn't really any way around it. You need to design your vertex layout so triangles can share the same texture coordinates (+ normals etc..)


So that means forget Index Buffering?
Nope. I've always used index buffers with my terrain engines and I find it works really well. It might just be a design-level change. Might well be that moving to triangle lists instead of strips might be an idea.

I usually implement my vertex buffer as being just the height-map points. I tend to use a few very large textures when making a terrain engine, so it's quite easy for vertices to share information.

I've then gone as far as creating an index buffer per quadtree node (make sure you use these) so I can despatch entire sections with only a couple of calls.

Quote:
Original post by Quinnie
I didn't started to implement this yet though so I don't have much knowledge of it yet
I highly recommend searching the forums for things like "terrain texturing", "terrain texture blending" and so on... I know I've been involved in several really awesome threads over the years. It's possible to come up with some seriously amazing visuals without it being too complicated - provided you think about it first [wink]

Quote:
Original post by Quinnie
when using Pixel Shaders would it be possible to set the uv mapping without implementing them into the vertexbuffer?
Not really. You could generate UV values in the PS, but I don't think they'll be any better than you've got at the moment.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by Quinnie
Quote:

There isn't really any way around it. You need to design your vertex layout so triangles can share the same texture coordinates (+ normals etc..)


So that means forget Index Buffering?

It doesn't really have anything to do with index buffers. An index buffer lets you specify the order of the vertexes, instead of being sequential. You don't have to reuse vertexes, if it is a problem.

Share this post


Link to post
Share on other sites
Going to the example of a cube, using indices you can has 24 vertices (4 unique vertices per face * 6 faces), rather than 36 (3 unique vertices per triangle * 12 triangles), because the two triangles on the cube face share the same normal and UVs along the shared edge. So, even with the trivial cube, index buffering still is a huge win.

Your terrain vertices likely often share UVs, blending, and normals, which will give it smooth texturing and transitions across many polygons. Most of the time your landscape will be like this, allowing you to share most of the vertices. You may occasionally want a hard transition in UVs or/and blending, or even position and normals for a sheer cliff. In these cases you'll need more vertices. These vertices will have an identical position, but they're not identical vertices.

Most modelling packages output vertices and indices based on position alone, then output UVs and normals per face. OpenGL and Direct3D both require you to combine the exported vertex and face information into one structure, then recreate your indices based on matches of the entire structure. During preprocessing I create a sort of linked list per exported vertex of all the variations of the vertex. When a face needs vertex 207, I check the list of full vertices at index 207, and look for one with all the appropriate data. If I find one, I use that vertices index rather than the original 207. If I don't find a match, I tack a new vertex on to the end of my vertex array, tack it onto the end of "vertex 207"'s list, and use the index of the new vertex.

Using a technique like this ensures I use the least possible vertices, while still allowing for each and every face to be using unique values. The list approach ensures I quickly find, or don't find, a match rather than searching all the vertices.

Share this post


Link to post
Share on other sites
Ok, thanks

I was a bit confused but I think I understand it now. Without Index Buffering U would have 2 * 3 Vertices for each Quad... Using Index Buffering only 4 Vertices Per Quad... Understanding that, I will resume writing my code :D Thanks a lot...

Share this post


Link to post
Share on other sites
Index buffers really come into play when you factor in the vertex cache of the card.

If you think about it - how does the T&L pipeline know what to keep in the cache and what to flush - it can derive this info from an index buffer since that tells the pipeline which vertices it can be expected to handle. So, without it a high-density mesh may be processing the same vertex multiple times rather than just once or a couple of times (the cache isn't infinite).

So - to help performance use an index buffer!

Share this post


Link to post
Share on other sites
Actually, as ntnet mentioned here a couple times, the Vertex Cache for processed vertices is a FIFO style buffer, with somewhere in the area of 16-24 vertices stored. I havn't heard anything about prediction in it.

It is, however, only available with indexed drawing.

Share this post


Link to post
Share on other sites
True it is FIFO but as you mentioned only available in index mode.. it uses the index to detect if the vertex is in the cache - didn't mean to imply any kind of prediction.... at the hw level at least - although that would be nice :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement