Reading the wonderful book OpenGL Game Programming I'm doing some collision detection. I define a plane from three points as they do in the book:

	vector_t v1(vector_t(vertex[3].x - vertex[0].x,
						 vertex[3].y - vertex[0].y,
						 vertex[3].z - vertex[0].z) | 1.0);
	vector_t v2(vector_t(vertex[3].x - vertex[1].x,
						 vertex[3].y - vertex[1].y,
						 vertex[3].z - vertex[1].z) | 1.0);
	N = (v1 ^ v2) | 1.0;
	D = -v1 % N;
  

My collision detection works fine except for one nasty snag: it seems very dependenton vertex ordering. All of the polys in my games are quads and are loaded in from a file. Because they're loaded in, I don't know how to specifically order how the plane is set up. What I mean is in OGL game programming's airhockey example they create the planes in code specifically ordering the vertices of how the plane is set up. But because I'm loading things in from a file I don't know how to do this. The following two polygons create planes that "work", points can't pass through them: 0, 0, 0, 0, 4, 0, 32, 4, 0, 32, 0, 0 0, 0, 0, 0, 4, 0, 0, 4, 32, 0, 0, 32 But the next one doesn't work at all for some reason. 0, 0, 32, 0, 4, 32, 32, 4, 32, 32, 0, 32 Is there a way I can calculate plane normals and distance without having to "rely" on the ordering of the vertices? Or, is there another way I can fix this problem? Thank you for any help! (EDIT: oh I forgot to note, that the plane initialization code uses OGL Game Programming's vector class, just in case someone didn't recognize those operators: ^ is cross product, % is dot product, N is normal vector and D is distance scalar) [edited by - rm3 on January 1, 2003 4:44:22 PM]

OpenGL faces are dependant on vertex order, so you can''t really get around it. Looking at the front of the poly, the vertices should be drawn counter-clockwise. The two examples you gave that work are drawn counter-clockwise. The example that doesn''t is drawn clockwise, so the poly faces the other way.

I suppose you could force the poly facing by including normal info in your file and re-ordering the verts if the normal points the other way, but that would be a lot of extra, needless work.

yckx

Thank you for the information! I suppose I don''t understand how to order vertices clockwise/counter-clockwise, because I thought

0, 0, 0,
0, 4, 0,
32, 4, 0,
32, 0, 0

was clockwise o_O Anyway I tried ordering the other polygon several ways, and going counter-clockwise I supposed it would be

0, 0, 32,
32, 0, 32,
32, 4, 32,
0, 4, 32

but it still doesn''t work. Can someone tell me how to get my vertices in order? This is driving meh crazy =)
Thanks!

It may be clockwise, it might not, the verticies alone give you no information. You're going to need to have normals (the direction it's supposed to be viewed from) to tell if the verticies need to be reversed.

If you do, you can take 3 verticies (dealing with triangles here) and subtract one from the other two, then take the cross product between those two, and then get the dotproduct between that and the normal. If the result is less than zero, you need to reverse the verticies.

(I think, I'm not that good with vector math.)

[edited by - smart_idiot on January 2, 2003 1:20:12 AM]

I don''t know what I was smokin'', but it must have been good. Looking at your original post, your third example is ordered just like your first, just with a different z-pos, so I would think it should work. I must not have been thinking clearly when I first looked at it.

That being said, I''m not sure that smart_idiot is fully correct. Everything I''ve read indicates that opengl assumes poly facing based on vertex order, which is pretty standard in computer graphics. You can do the vector math to verify it, but so long as the verts are supplied ccw, I don''t know what the problem might be.

Sorry.

yckx