Index Buffers to store 3D Geometry
Written : 27th December 2000
Contact : [Web]
Download : Graph_09.Zip
of this lesson:
2. Generating our geometry
3. Rendering our geometry
back to the second of the advanced geometry tutorials, things should be starting
to fall into place now - and you should be more than capable of creating a very
basic 3D engine with your current knowledge. However, there are still a few
things to learn before you can create a reasonable, modern 3D engine for your
lesson is going to discuss one trick that you may well find extremely useful
if you go onto develop your own engine. Indices - these are a series of numbers,
stored in an index buffer, that reference vertices in a vertex buffer. They
may not seem very useful, but you can reduce your vertex count 10 fold using
them. Consider the cube that I've shown you in several previous lessons. With
your current knowledge you could create it using 36 vertices, 18 if you're clever;
or you could just generate it using a 3D modeller and import it in as an .X
file. The first way is very inefficient, you're using up a large number of vertices
for a very very simple piece of geometry. The second way is okay, but can be
a bit of a pain when it comes to changing the colours and textures. Now consider
the use of an index buffer...
index buffer is basically a series of numbers (of integer datatype); these numbers
reference (any number of times) vertices stored in a vertex buffer. For example,
we could generate a vertex buffer in with 8 vertices defining a cube, we could
then create an index buffer with 36 entries in it (same number of vertices as
used before) to reuse those vertices. Think of it like this - the indices for
triangle 1 could be 0, 1 and 3 - which, to the renderer, says: "Make a
triangle using vertices 0, 1 and 3". So, all of a sudden our cube becomes
8 vertices instead of the original 36 vertices.
way of thinking about it is to realise that of those 36 vertices we've previously
used anything from 3-6 vertices have shared the same world-space position, and
the same colour; so why not represent those 3-6 vertices with only 1...
of the main uses I've found for indices in the past is when making custom file
formats. You can store the data in a file for 3500 vertices and end up with
a rather large data file, or you could store 1200 vertices and a list of 3500
indices and get a relatively small file.
the fact that indices and index buffers are extremely useful, there are also
several downsides to using them, the main one being that all indices sharing
the same vertex must have the same properties - same position, same colour,
same texture coordinates, same normal.
In our cube example we couldn't redesign it so that one face was blue,
one face was green and so on.... each face would blend into each other
Texturing becomes really difficult. How would you set texture coordinates
for our cube so that you got different parts of a texture on each face - or
a different texture on each face. There are some tricks involving mult-pass
texturing and multiple stage texturing, but their not always available and are
often quite slow.
Lighting normals must be the same, this isn't too difficult as you average
the normals for the 3 sides of our cube using addition (as illustrated in the
lighting tutorial). Because all the normals will be averaged it sometimes looks
a little odd - not always, but sometimes the lights appear to behave incorrectly
and unnaturally - something you want to avoid when making realistic / semi-realistic
arguments for and against have been laid out, it's up to you to decide if and
when you want to use index buffers. Either way, it's useful to know how they
Generating our Geometry
this part actually gets much easier when using index buffers; Hopefully you've
been following the series from the beginning, and you should remember the several
occasions that I've made a cube in the sample application - and in the "InitialiseGeometry(
)" procedure we have 150 lines of repetitive code for generating a simple
cube. You may not have realised it, but it was an absolute pain to search for
an incorrect vertex in there - and writing the code from scratch was annoying
enough. Using indices we create 8 vertices and 36 indices, if the vertex positions
are wrong I have 8 of them to look through - not too hard, and if the indices
are wrong I just have to juggle a few numbers around.
BailOut: '//Setup our Error handler
'//1. Generate the 8 vertices for our cube (2x2x2 in size)
'//2. Create the vertex buffer
'//3. Generate our indices
'//4. Create our index buffer
easy isn't it. I've written all the indices so that there is 1 triangle per
line - 2 triangles per face with a heading. The indices still need to be in
the correct order - clockwise usually, and you cant put invalid vertex numbers
in- so you still have to be a little bit careful.
first stage, whilst it doesn't have to be, is creating the vertices and vertex
buffers - we've covered them in previous lessons and aren't that difficult so
I'll skip straight along to indices and index buffers.
first part of generating indices is to fill the correct sized array with the
correct values - the array is of type integer and has the same number of elements
that we'd normally use when creating vertices - for a cube this would be 36.
second part creates a blank area in memory for holding our array of indices;
this must be done before we try and fill the buffer with our data - otherwise
some strange memory errors are going to appear. To create an index buffer we
use the D3DDevice.CreateIndexBuffer( ) call, which takes the following parameters:
As Long = How much memory we need to allocate, this is basically "Len(
first element in array ) * number of elements in the array"
Usage As Long = This allows the device to place our index buffer in the
most efficient place available; see the "D3DUSAGE_" flags in the object
browser. Leave as 0 for most applications
Format As D3DFORMAT = What format the indices are, D3DFMT_INDEX16 and
D3DFMT_INDEX32 are the only valid flags; use D3DFMT_INDEX16 if you're using
an integer array, and D3DFMT_INDEX32 if you're using a long array - but it's
unlikely you'll ever need to go above 32767 indices anyway (even if the driver
lets you) so an integer array will almost always suffice.
Pool As CONST_D3DPOOL = Where you want the index buffer to be stored.
This can usually be left as D3DPOOL_DEFAULT, but if you intend to keep changing
the contents it's best to place it in system memory - D3DPOOL_SYSTEMMEM; D3DPOOL_MANAGED
allows DirectX and the driver to shift it's location around as it sees fit....
we fill the index buffer with our data; this is almost identical to filling
a vertex buffer with data. It uses the hidden procedure "D3DIndexBuffer8SetData",
which takes these parameters:
as Direct3DIndexBuffer8 = The index buffer we're using, this must be created
first - as we've just done.
Offset as Long = Where we start writing the data (in bytes); this should
be 0 if this is the first write; otherwise you can set it to other values should
you wish to insert data later on.
Size as Long = How big the Index buffer is - the same as we specified
when creating it; this shouldn't be any bigger than you created it, otherwise
it'll write to memory that doesn't belong to it and it'll give you an error,
if not crash the whole program.
Flags as Long = A combination of the CONST_D3DLOCKFLAGS enumeration;
this can be left to 0 for a first write, other values should be specified when
resetting data later on.
Data as Any = the data that we want to fill it, defined as "Any"
so that we can pass any datatype to the procedure. This will be the first element
in our array of indices that we want copying; if you wish to start elsewhere
specify a different array entry - CubeIndices(12) for example...
this point in time we'll have a functioning vertex buffer and index buffer -
all the information we need to render our geometry; if we really wanted we could
discard the vertex array and index array - but they may well prove to be useful
later on, it all depends on your engine/application though....
Rendering our Geometry
the geometry isn't greatly difficult, it just requires that we tell the device
where our vertex buffer is, where our index buffer is and what to render. This
is accomplished through the following code, which goes between the D3DDevice.BeginScene
and D3DDevice.EndScene calls (which I shouldn't really need to remind you about).
we tell it which vertex buffer we're using and what size the information is
- something you should be able to do by now. Then we tell it which index buffer
to use, and a base value - this value is most interesting if you're using different
vertex buffers but the same index buffer. This value is added to all indices
before their referenced to the vertex buffer - effectively setting it so that
you're referencing a whole new section of the vertex buffer. For example, if
this were set to 10, the first triangle 0,1,2 would actually reference 10,11,12
in the vertex buffer... (This is called the BaseVertexIndex)
we actually render the geometry - Using a new rendering call. The parameters
go like this:
PrimitiveType As CONST_D3DPRIMITIVETYPE = How the vertices/indices are
arranged - you should be able to do this; it was described in the basic geometry
section. This should be the same as how you've designed the indices.
MinIndex As Long = This is the same as the BaseVertexIndex value in the
NumIndices As Long = The number of indices Direct3D will use, starting
from BaseVertexIndex + MinIndex
StartIndex As Long = The location in the index buffer to start reading
PrimativeCount As Long = The number of triangles being rendered.
above call, with the 12 and 36 numbers changed should be suitable for most uses;
but one final note - D3DPT_POINTLIST is not supported for indices and should
not be used.
all you need to know about drawing index based geometry - not too complicated
really, and quite a neat trick to learn. I suggest you download the source code
for this lesson, as a lot of the missed out things are the basic framework we
have built up over the last 8 lessons.
you think you've understood that, or just dont care, you can move onto Lesson
10 : Advanced Geometry part 3 - Vertex / Mesh animation.