Originally Posted by

**m3rk**
By the way, I didn't apply any linear algebra here. I don't know how to apply it here in opengl. I hope someone will teach where to use it.

Maybe it could be applied to the program flow, ie. how the game operates, since that actually has nothing to do with GL.

IMO, w/r/t rendering & such, trying to apply your knowledge of formal math may not be necessary or even helpful. I think this is because the conceptual reality of a 3D engine is different than that of a math lab (not to "denigrate" either one).

Here's a story to illustrate my point: I'm a total novice with openGL. The other day I was writing a function to create a non-curved cylindrical object with any number of sides (eg, something that might look like a symmetrical skyscraper with 6 or 7 sides). I was using quads to do this and couldn't get the length of a side (pictured orthographically from the top, such a cylinder would be a "regular polygon") to work out, so basically the sides were two long ("length" in relation to the orthographic top view, not the tower height, so in sense the "width" of a side). I was using the diameter of the cylinder as a function parameter, and I figured there must be a formula to determine how long a side should be in relation to the diameter of a regular polygon*. I learned there are actually (at least) several such formulas, only one of which is a straight-forward enough equation to be implemented in one line in a C program. When I did it, however, the sides were still a little bit too long. Finally I gave up on algebra and just figured I should divide 360 by the number of sides, rotate, translate the length of the side (so I changed the function parameter to that, instead of the diameter), and draw the side, which works. You (or at least I) might think after reviewing the algebra of regular polygons that somehow 180*(sides/2) is involved, but even that is not. This is what I mean by the different conceptual setting.

It could be that using an equation may be more optimized which is super important with 3D games, but since the GL functions should already be optimized, it is not necessarily so. For example, trigonometry is elegant, but I see no reason to believe that a couple of sinf/cosf calls are less expensive than a single glRotate. The only problem is you cannot call glRotate between glEnd and glBegin, whereas you can use math lib functions as much as you want.

**RE: Surface Normals** What do you think is weird about the lighting in your "weird lighting"? It looks like the roof maybe "unlit". How are you determining the normals? If you are using a function like this one:

Code:

void setnormal (vect P1, vect P2, vect P3) { /* from openGL wiki pseudo-code */
vect U,V;
vectminus(P2,P1,U);
vectminus(P3,P1,V);
Normal[0]=(U[1]*V[2])-(U[2]*V[1]);
Normal[1]=(U[2]*V[0])-(U[0]*V[2]);
Normal[2]=(U[0]*V[1])-(U[1]*V[0]);
}

which I think is kind of a standard thing that accepts three points on the surface, I've noticed that *the order of those three points *can reverse the normal, making a supposedly lit surface unlit except for ambiance. ("Normal" in this is just a global variable used with calls to glNormal3fv(), since there is no need to keep more than one at a time anyway).

*Of course, there are TWO obvious ways to measure the diameter, corner to corner or side to side. That may be where I went wrong....