Normalizing vertex arrays

Started by
5 comments, last by Alex Baker 18 years, 1 month ago
Hello, I found this code to render a vertex array with seperate indices for the vertices and the texcoords: http://www.mindcontrol.org/~hplus/graphics/vertex-arrays.html But when I use it in my exporter, it keeps locking up. The function returns an unusually low number (2400 verts --> return value = 4). What does this number represent and does anybody know why it keeps on locking up? Oh and btw, it says something about passing in enough "space". Does this mean that I have to do something like this: vert *vertout = new vert[NumOfVertices]. If so, how do I know how much space?
Advertisement
By fixing a problem with my indices, I've been able to get it working (sort of). The function now returns a number around 4000, which seems acceptable. But what does it actually signify?

Btw. when I render it, the geometry seems correct, but the texture doesn't show up. Very weird, but it might be another problem...
GodModder,

what do you mean by "locking up" ?

the term "normalizing vertex arrays" means, instead of having an (vertex/uvcoord) array with one position for each vertex/uvcoord it says you have an array of indices indexing into (!) an array of vertex/uvcoords - this way you can save rendering time by re-using already used vertex/uvcoords.

though, i haven't read the article...

Alex BakerComputer science is dealing with computers as much as astronomy is dealing with telescopes.
The code doesn't lock up anymore. The function now returns a value of around 4000 for a model of 2800 verts, 12000 texcoords and 12000 indices.
The code is meant to be used in my exporter for 3dsmax. (I'm using the IGame SDK wrapper) It's amazing how many resources there are on writing exporters, but how few are about loading the data back into your app.

Now, the data that comes out of Max has this format: - vertices (e.g. 2800)
- texcoords (e.g. 12000)
- indices into the vertex array
- indices into the texcoord array

I must use the following format for OpenGL to render: - vertices
- texcoords
- indices (vertex/UV)

Now, first, I don't know what the value means that the function returns. I assume it is the resulting number of vertices/UV coords, as they must be the same in the end. The resulting number of indices doesn't change.

The exporter seems to run now, but when I load the data in my app, the geometry loads fine, but it's all black instead of having a texture.

Btw.: I've also written a .3ds loader for my engine and those objects load perfectly fine. Although the number of vertices is quite different to that of my exporter (around 6000).

PS: normalizing the vertex arrays is a term used by the author of the site...
For the newcomers: the site containing the problem code is: http://www.mindcontrol.org/~hplus/graphics/vertex-arrays.html
Anyone? There's no resources on this topic on the internet, so I'm really dependend on you guys right now...
godmodder,

you need to do two passes:

(assuming a model with a MAX facecount of 800, MAX vertex count 1000 and MAX uvcount with 500, this is because MAX is re-using vertices/uv's/ect. )

first step: creating a "linear" array (without any indexbuffer):
"unroll" the MAX array to a temporary array that the count of vertices & uvcoords will be three times of the MAX facecout - so you will end up with a facecoutn of 800, a vertex count of 2400 and a uvcount of 2400, because: til now you will have a seperated (!) set of vertices&uvcoords for each triangle (yes, highly unoptimized til this point).

second step: creating the optimized array version (filling your index buffer):

everything you have to do now, is, to iterate over this "big-as-three-times" array (vertices&uvcoords) to find out, which vertex/uvcoord is already used - if this index is of a given vertex/uvcoord is already in your new ("final") array, then you won't add it, instead you return an index to this already-existent vertex/uvcoord pair in this new array.

you will notice a veeeerrry long transformation time, now - because: (imagine a 30k face mesh) you have to compare vertex per vertex per vertex and so on ...(doing the above math will result in 90k vertices needed to be compared to each other!) at this point, it's useful to implement an additional hashtable to speed up comparing - this will cut down mesh's transformation time down to 5 - 10%. it also working without this additional hashtable but you can go and drink a coffe when exporting a 10k mesh :)

as already said: may sound a little bit complicated but this is the only way to get the MAXdata exported to your engine by having it looking like as it does in 3DSMAX.

Alex BakerComputer science is dealing with computers as much as astronomy is dealing with telescopes.

This topic is closed to new replies.

Advertisement