Advantage of using index buffer.
Author
Hi all, i have some problem.
Advantage of using index buffer is save memory..... have another ?
If i draw a cube with TRIANGLE LIST
Using only vertex buffer, 36 vertices used, Vertex transform happen 36 times.
Using vertex+index buffer, 8 vertices and 36 indices used.. How many vertex transforms ? 36 times like using only vertex buffer, or pre-transform 8 times on each vertex, and then arrange by index.
36 or 8 or ?????????????
Thx a lot :)
Well when you set the world matrix anything in the vertex buffer will be transformed, so 8 transformations.
ace
ace
The advantages of having an index buffer depend on the kind of geometry you're rendering. In general, an index buffer not only saves memory but time as well.
Graphics chips have something called a vertex cache inside of them. This cache is where they store recently transformed vertices for possible future use. The idea is similar to the cache present in regular CPU's. When using an index buffer, the graphics chip will transform the vertices indicated by the index buffer and place these results in the vertex cache. If the index buffer later on tries to reuse one of the vertices that the graphics chip has already transformed, the chip will simply fetch the transformed result from the vertex cache instead of performing the transformation again. It cannot do this if you don't use an index buffer because the graphics chip would have no way of knowing that the vertex you want it to transform is exactly the same as a vertex it had already transformed earlier.
Also, the case of a cube is not very common. If you do not use an index buffer, it is true that you need to use 36 vertices. Now, if you use an index buffer and your cube does not have any normals or texture coordinates, then you can get away with only using 8 vertices and 36 indicies. In this particular case, all 8 vertices will probably fit in the vertex cache of your graphics card and can be reused to render the entire cube without having to transform the vertices more than once. However, if you want your cube to have normals and texture coordinates, then you're going to end up having 36 disticnt vertices even if you're using an index buffer. The reason for this is that the texture coordinates and normal vectors for a given point on the cube are different depending on which face of the cube you're specifying. In this case, an index buffer doesn't really save you anything. But this case isn't very common in the real world. Most models created by artists make heavy reuse of the same vertex information to specify a number of primitives. In these cases, using an index buffer can greatly help not only memory consumption, but performance as well.
neneboricua
Graphics chips have something called a vertex cache inside of them. This cache is where they store recently transformed vertices for possible future use. The idea is similar to the cache present in regular CPU's. When using an index buffer, the graphics chip will transform the vertices indicated by the index buffer and place these results in the vertex cache. If the index buffer later on tries to reuse one of the vertices that the graphics chip has already transformed, the chip will simply fetch the transformed result from the vertex cache instead of performing the transformation again. It cannot do this if you don't use an index buffer because the graphics chip would have no way of knowing that the vertex you want it to transform is exactly the same as a vertex it had already transformed earlier.
Also, the case of a cube is not very common. If you do not use an index buffer, it is true that you need to use 36 vertices. Now, if you use an index buffer and your cube does not have any normals or texture coordinates, then you can get away with only using 8 vertices and 36 indicies. In this particular case, all 8 vertices will probably fit in the vertex cache of your graphics card and can be reused to render the entire cube without having to transform the vertices more than once. However, if you want your cube to have normals and texture coordinates, then you're going to end up having 36 disticnt vertices even if you're using an index buffer. The reason for this is that the texture coordinates and normal vectors for a given point on the cube are different depending on which face of the cube you're specifying. In this case, an index buffer doesn't really save you anything. But this case isn't very common in the real world. Most models created by artists make heavy reuse of the same vertex information to specify a number of primitives. In these cases, using an index buffer can greatly help not only memory consumption, but performance as well.
neneboricua
Even if you are using normals and texture coordinates for a cube, you would save some vertices, wouldn't you? (4 verts for each face of the cube, rather than 6)
I think most people, (including I know some from ATI and NVIDIA) will say you should pretty much always use index buffers to get the best performance.
I think most people, (including I know some from ATI and NVIDIA) will say you should pretty much always use index buffers to get the best performance.
It depends on the card and the order of the indices. Most cards have post transform caches, which when used with indexed rendering can save a lot of transforms. the size of the cache determines the amount of transformation. I could be quite wrong but I believe most NVIDIA cards have somewhere on the order of 10-15 vertices cached. You might want to check the nvidia developer website if you want more information. Ati may have some information as well.
In general, indexed rendering is better than non-indexed. This is from transform caching and overall bandwidth savings. It can also save a lot of memory. Obviously, if you format your data in a way that it can't cache well (ie jumping around all over the vertex buffer) the performance can be the same or worse as non-indexed. But thats a pretty extreme case. If you look in the directx docs, there is an Optimize function that can format your index and vertex data for the card you are running on. Nvidia also has an nvidia utility which does the same.
Now, if your just trying to get something rendering, do whatever is easiest for you first. Get it on screen, then worry about the "right" way and more optimal ways.
Hope that helps.
This is somthing i am always wondering,
i known that vertex buffer save memory and give best perfomance but in videogames, for every frame the scene is rebuilt (so not less than 33 times each secs), the scene and then most the time individual triangles are checked about frustum for discard what it is not seen by current camera aim, so actually you always finish having a different list of visible triangles for the current frame; then those triangles have to be sorted by texture or material (to minimize changes texture stage) and even somtimes by distance for drawing from back to front (if you are going to use blended effect); at this point i am ready to send the triangles to the videocard...i am wondering if it is realy worth spending more time building a vertex and index buffer, averaging the normals in all shared vertices and then passing the vertex + Index buffer to the videocard...dont you think it should be faster to pass the triangle list and avoid the index buffer building procces?, what ever i gain in perfomance with vertex + index buffer it is lost when using time for averaging the normals in shared building and building the indexed buffers; I cant precalculate the vertex+index buffer coz it have to be built every frame depending where the camera is looking at...
What you think? it is vertex+index buffer worth for rendering dynamic scenes?
tp.
i known that vertex buffer save memory and give best perfomance but in videogames, for every frame the scene is rebuilt (so not less than 33 times each secs), the scene and then most the time individual triangles are checked about frustum for discard what it is not seen by current camera aim, so actually you always finish having a different list of visible triangles for the current frame; then those triangles have to be sorted by texture or material (to minimize changes texture stage) and even somtimes by distance for drawing from back to front (if you are going to use blended effect); at this point i am ready to send the triangles to the videocard...i am wondering if it is realy worth spending more time building a vertex and index buffer, averaging the normals in all shared vertices and then passing the vertex + Index buffer to the videocard...dont you think it should be faster to pass the triangle list and avoid the index buffer building procces?, what ever i gain in perfomance with vertex + index buffer it is lost when using time for averaging the normals in shared building and building the indexed buffers; I cant precalculate the vertex+index buffer coz it have to be built every frame depending where the camera is looking at...
What you think? it is vertex+index buffer worth for rendering dynamic scenes?
tp.
You shouldn't be averaging normals of triangles and doing in-depth sorting every frame. These are things that should be done as a preprocess. Sorting by texture and material should be handled by the game engine using dynamic index and vertex buffers.
The engine should render all polygons associated with a particular texture or material by copying their vertices into dynamic index and vertex buffers. Once these buffers are built, the engine can iterate through all the materials and call DIP on the corresponding parts of the index and vertex buffers.
Building an engine that does all this is not a trivial task. However, using an index buffer along with the vertex buffer will help performance by reusing already transformed data and will save memory (hence bandwith, and therefor increase performance) by being able to avoid duplicate vertices.
neneboricua
The engine should render all polygons associated with a particular texture or material by copying their vertices into dynamic index and vertex buffers. Once these buffers are built, the engine can iterate through all the materials and call DIP on the corresponding parts of the index and vertex buffers.
Building an engine that does all this is not a trivial task. However, using an index buffer along with the vertex buffer will help performance by reusing already transformed data and will save memory (hence bandwith, and therefor increase performance) by being able to avoid duplicate vertices.
neneboricua
You mention both culling and sorting. Both of these operations are easier to do with index buffers. In the case of culling, you only select which indices you want to draw, and then you only change the index buffer, not the whole VB (16 bits for an index as opposed to my average 48 bit vertex). The exact same goes for sorting. When sorting, you only need to sort 16 bit objects, so you're doing less work (mostly, might be different in some cases if you use pointers), but after you're done sorting, you're sending much less data to the GPU, which would give you a speed increase (might not be too big, but still, in retail games every single FPS is worth it's weight in gold :)).
Quote:Original post by ace_lovegrove
Well when you set the world matrix anything in the vertex buffer will be transformed, so 8 transformations.
ace
i don't understand... does this mean than Eg i have a super big static vertexbuffer that stores all the static meshes of the scene.
Then i wish to render only a particular mesh say "Mesh A" in the vertexbuffer, hence i call:
SetWorld() - Eg to rotate Mesh A by a matrix
DrawIndexedPrimitive() with the proper offset values to the correct vertex
Will SetWorld transform every single vertex in the vertexbuffer, including thoes meshes that i am not going to render?
Quote:Original post by Anonymous Poster
This is somthing i am always wondering,
i known that vertex buffer save memory and give best perfomance but in videogames, for every frame the scene is rebuilt (so not less than 33 times each secs), the scene and then most the time individual triangles are checked about frustum for discard what it is not seen by current camera aim, so actually you always finish having a different list of visible triangles for the current frame; then those triangles have to be sorted by texture or material (to minimize changes texture stage) and even somtimes by distance for drawing from back to front (if you are going to use blended effect); at this point i am ready to send the triangles to the videocard...i am wondering if it is realy worth spending more time building a vertex and index buffer, averaging the normals in all shared vertices and then passing the vertex + Index buffer to the videocard...dont you think it should be faster to pass the triangle list and avoid the index buffer building procces?, what ever i gain in perfomance with vertex + index buffer it is lost when using time for averaging the normals in shared building and building the indexed buffers; I cant precalculate the vertex+index buffer coz it have to be built every frame depending where the camera is looking at...
What you think? it is vertex+index buffer worth for rendering dynamic scenes?
tp.
Maybe I am not understanding, but why are you testing each triangle by hand ? Modern video cards do transform and clipping on the hardware (and its fast). Are you not using hardware ? Even with that said, most games (even in software) pre-build batches of triangles (usually based on material and locality in the scene, or object) and store bounding boxes (or spheres, or insert any volume). They do frustum tests with the bounding volume to determine if its completely outside. If not, they just send it to the renderer. Dynamic buffers are used for particles or items that must be generated at runtime only. Try to keep as much static as possible and do quick tests to determine if you are sure its outside of the camera. What makes your scene so dynamic ? If its only the camera is moving, thats not really dynamic. If all of your meshes are changing topology then thats another story.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
