My understanding of Culling is that if something opaque is in front of something else, whatever is in the back will not be drawn. If this is correct, I'm having problems with the triangle fan. It can be seen through some shapes, but not through others. I've shown the drawing code below, and linked to the full code (which includes rotation via the arrow keys, and reset with the space bar) here: http://www.theouterrim.net/Test1.java Would someone please tell me what I'm missing in the geometry here? Thanks.

Not drawing objects that are obscured by other objects is sometimes called "z-buffering" or "occlusion culling", but in OpenGL it is called "depth testing".

The "face culling" methods in OpenGL are a fast way of eliminating polygons that can't be seen - if a polygon is facing away from the camera it can just be ignored.

As to why the triangle fan isn't being depth tested correctly, you're clearing the depth buffer to 1.0f, not the more usual 0.0f and you're specifying a 0 bit depth buffer (in the GL constructor). If you fix those two, the depth-buffering should work correctly.

Just as a warning, you're pushing more matrices than you're popping! Your resizeGLScene method pushes both the projection and modelling matrices, but nothing in the program pops them again. As the projection matrix stack may only be two deep, calling resizeGLScene twice may cause OpenGL to error. You're not storing the matrixes for any reason, and just loadIdentity straight after, so it's probably worth just deleting those lines.

So you're saying that I should change the line:gl.clearDepth(1.0f);to:gl.clearDepth(0.0f);

What should I change the bit depth buffer, specified in the constructor, to?

If I just change gl.clearDepth(1.0f); to gl.clearDepth(0.0f);, then nothing is drawn.

For the resizeGLScene, could you please give me specific line numbers? When I start changing things, nothing gets drawn. However, if you mean just removing the push statement, I've removed those and my program still draws.

What should I change the bit depth buffer, specified in the constructor, to?

Anything non-zero really. 8 bits would probably suffice.

Quote

For the resizeGLScene, could you please give me specific line numbers? When I start changing things, nothing gets drawn. However, if you mean just removing the push statement, I've removed those and my program still draws.

Whenever you have a pushMatrix statement, there should be a corresponding popMatrix at some point. The matrix stacks aren't infinitely large, and the projection matrix in particular need only be two deep by the OpenGL spec. You'd usually need to pushMatrix if you were about to do something destructive to the current matrix but want to get the current one back later.

So yep, just remove the pushMatrix calls in the resizeGLScene method. The program will still work as expected, but you save yourself a nasty bug further down the line!

hmmm... That didn't solve it. I can still see some of it. Since that is about 1/3rd the polygons, this will have some performance issues. Would you advise switching to plain triangles instead of strips? Because the regular polygons aren't giving me any trouble.

Now I'm onto curves. Everything draws more or less correctly, except if you run the code I've provided, on the right side, the top and the side do not meet. This is strange, since they should be the exact same locations.

Nevermind, I fixed it. It has something to do with my translate calls. Not sure what, but I removed to translate calls within the gl.begin and gl.end and edited the values. For some reason, that fixed it. Can't translate calls be put within a gl.begin/gl.end?

Ah, no. The only commands valid between a glBegin and a glEnd are as follows:

glVertex*

glColor*

glIndex*

glNormal*

glEvalCoord*

glTexCoord*

glEdgeFlag*

glMaterial*

glCallList(s)

While within a begin/end pair you're supposed to be defining vertices to make up an OpenGL primitive of some kind. Anything that isn't directly concerned with this process or changes the context in which those vertex calls are made is disallowed.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org