How do people deal with .OBJ models that the faces with different amount of vertices? I see most use either 4 or 5, but it's unlimited, how do you detect this?

Edit - I figured it out

either use GL_POLYGON, or, [much] more efficiently, tessellate the face yourself.

or is that not what you were asking

I use GL_TRIANGLES for all faces with three sides GL_QUADS for all faces with four sides and GL_POLYGON for anything over that. I don't bother with tesselating for efficiency since I figure that's what the triangulate function is for in the 3D editor that created it in the first place! I'll draw it, but it's not my fault if the artist doesn't know that real-time rendering is faster with triangles...

Woah, that's weird... I was doing some Googling on tessellation and this thread showed up in the results. Must be that it's fresh or something.

Anyway, after reading it again I somehow feel obligated to comment on my comment (hehe) and point out that GL_POLYGON is a lousy one-size-fits-all solution. I only use it so that some geometry will show up on-screen, but it isn't always right. There is a real possibility that one will be dealing with non-simple polygons, like non-convex polygons, if the file contains polygons other than triangles or quads, and GL_POLYGON doesn't like non-convex polygons!

BTW, does anybody have any good links for tessellation algorithms?

I'm looking into whether or not it would be worthwhile to go ahead and correctly render n>4-sided polygons for a change (my my how things can change in two days). I'm actually just now looking at gluTess for the first time -- it looks like a real pain on first glance, but perhaps that would be the best way to go. However, I was originally thinking it might be nice to tessellate it myself so I can keep the raw geometry.

AnotherJake Wrote:BTW, does anybody have any good links for tessellation algorithms?

Never mind. Everywhere I look, everyone says writing your own tessellator is no fun (impossible is more like it), and that GLU's tessellator is where it's at. So I guess that's the direction I'll take first.

tesselating convex polygons is a matter of triangle-fan and putting the vertices in the right order, anything more complex can be handled by this amazing piece of software Triangle!

Triangle looks pretty neato! I'll have to check that out for sure.

Yeah, convex polygons are a snap with fanning, but I don't really care about convex polygons since those can be rendered correctly with GL_POLYGON. That is, unless I wanted more efficiency, using something like glDrawElements I suppose. Right now I'm mainly interested in *correct* drawing of complex polygons (concave, self-intersecting). But anyway, the only problem with fanning is that it tends to produce lots of triangles with one particularly small angle at the vertex you fan from. It's usually not a problem but small angles can make calculating normals a little less accurate. A person could subdivide the polygon instead I suppose.

I would actually calcuate the normal of the polygon and then triangulate it, giving each of the triangles that pre-calcuated normal but theres 1 billion and 1 ways to do anything.

Yeah, I guess that's the way I'd do it too. Actually, I already calculate normals beforehand if they're missing, so they'd already be there before tessellation anyway. That wouldn't help with dynamic geometry though.

For some reason, I'm having a problem displaying QUADS. Everthing seems to be correct. I've even printed out the line I've read in, and made sure after actually storing the indices and vertices in an array, that they were correct, so I believe it's how I'm drawing it.


edit - It seems that the vertices that should be drawing isn't, until the next loop.

IE, I printed out the vertices being drawn (for a cube), then compared it to the actual file, then recorded them. All the x y z values are either .5 or -.5, so I just recorded whether it was postivie or negative.
If needed I'll post the rest of my loading code.

Thanks for any help!

One thing that sticks out is that you're using an upper case J++ in your for statement instead of a lower case j++

Yeah, I changed that last night before I went to sleep, and didn;t compile it again until after this post (I just was messing with the loop, but with j++ was how i originally had it). Please see the edit

It *looks* like your drawing code is sensible. The only itty-bitty minor issue (and apparently unrelated to the problem at hand according to your printout) is that temp.NumVerts should really just be 4 since you'll never want to attempt to do more than 4 verts in a GL_QUADS block. The only logical guess I can make is that your VertIndices are one high when you load your model. Don't forget that obj indicies start at one and not zero!

It's odd, because loading a model with triangles seems to work fine (of course, I modify the drawing routine to fix to GL_TRIANGLES).

This is basically how I actually load the vertices
VertIndices is just a pointer I allocate memory based on NumVerts.
As for the whole code, here it is. It may be possible that the triangles are wrong too, but when loading some pretty complicated models it *seemed* to work, but I may be wrong.
Header: http://rafb.net/p/xcNRls80.html
CPP: http://rafb.net/p/nDzzzZ54.html

I can post the whole project if anyone wants to test..

Edit - Well, the triangles code is wrong also, just on the model I was using, there were so many faces it was hard to tell. Also, I discovered that mFaces would always be on more then it should be. So if there's 12 faces, it loads in 13 and the 12th and 13th face is the same :/... I'm not sure why, as the same method for vertices, UVs and normals is working (for the cube I'm not testing, there is 8 vertices, and it says there is 8 vertices.).

Unless I am mistaken, aren't all those integers that you're scanning in from the .obj one higher than the index they are supposed to be? (obj indices start at 1, not 0) I'm surprised you're not crashing if that is indeed the case.