Quote: "What is the difference between an object that does and doesn't have indices? How does that affect the object or what your trying to do with it?"
I'll quickly answer this with an example so there is no confusion. Imagine we wanted to draw a quad. This would require two triangles, so 6 vertices in total:
vertexdata:
-1, -1, 0 (bottom left)
-1, 1, 0 (top left)
1, -1, 0 (bottom right)
1, -1, 0 (bottom right)
-1, 1, 0 (top left)
1, 1, 0 (top right)
Assuming we're using DBPs default FVF, that's 36 bytes per vertex, so the quad would be using a total of
216 bytes.
Index buffers become useful when there are a lot of duplicate vertices in a model, and this is almost always the case with any decent model in existence. We can therefore optimise:
vertexdata:
-1, -1, 0 (bottom left)
-1, 1, 0 (top left)
1, -1, 0 (bottom right)
1, 1, 0 (top right)
indexdata:
0, 1, 2 (triangle 1)
2, 1, 3 (triangle 2)
Now we're using only 144 bytes of memory for vertices and 3 bytes for indices (one index is an unsigned short in DBP), a total of
147 bytes.
When the GPU renders the object, it will convert the vertexdata/indexdata into an un-indexed vertex stream identical to the first example, which gets fed in to the rendering pipeline.
Quote: "I guess each has there cons and pros?"
Not only do indices save memory and file size, they will also speed up the time it takes to render the object, because the GPU can perform cache optimisations on the vertex data (reading the same vertex a second time will be a LOT faster if it was cached the first time).
The only case in which indices make no sense is when there are no shared vertices.
Quote: "TheComet, still the same problem, as with your example you use memblock (it's actually the same method I use that I even credited you for in my work). If I wanted to face test for vertices of every object that goes in my world, I can't make a memblock of all of them... or can I? I have no clue how this would affect performance"
The problem is, SC_GetFaceHit() returns a face ID, which when multiplied by 3 gives you the un-indexed vertex ID, and it is impossible to reverse lookup to see which index it belongs to.
My suggestion to you is: For every unique object you load, extract the information you require into a DBP array. If the only thing you're interested in about the face being hit are the vertex positions, then you might do something like this:
type VertexDataT
x as float
y as float
z as float
endtype
load object "myobj.x", objID
dim vertexData() as VertexDataT
make mesh from object 1, objID
make memblock from mesh 1, 1
vertexCount = memblock dword(1, 4) : rem I think it's the second dword, may need to check
vertexSize = memblock dword(1, 8)
for i = 0 to vertexCount-1
offset = i*vertexSize + 12
array insert at bottom vertexData()
vertexData(i).x = memblock float(1, offset + 0)
vertexData(i).y = memblock float(1, offset + 4)
vertexData(i).z = memblock float(1, offset + 8)
next i
delete memblock 1
delete mesh 1
(obviously you will want to have an array of vertexData() arrays, so you can maintain lists of multiple object's vertices).
This will be more memory efficient than keeping a memblock around because you're only storing the data you're interested in, and it will give you very fast results because you can directly look up the three vertices from the array.
The only way to do great work is to love what you do -- Steve Jobs
