Index Buffers
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
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
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...
Quote:Original post by QuinnieNope. 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.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?
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 QuinnieI 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]
I didn't started to implement this yet though so I don't have much knowledge of it yet
Quote:Original post by QuinnieNot 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.
when using Pixel Shaders would it be possible to set the uv mapping without implementing them into the vertexbuffer?
hth
Jack
Quote:Original post by QuinnieQuote:
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.
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.
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.
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...
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...
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!
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!
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.
It is, however, only available with indexed drawing.
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 :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement