# OpenGL White "seams" between cubes

## Recommended Posts

Okay, I was working on a little 3D engine and I am using cubes (scaled to 2x their height) to represent solid tiles. Here's the problem: Yup. Lookit them seams. They sure are ugly. I render the cubes using a display list of GL_QUADS (the same problem persists if I render them with a display list of GL_TRIANGLES). Here's my map drawing code:
void CGame::drawFPMap(float playerX, float playerY, float playerZ) {
int tx = (int)playerX;
int tz = (int)playerZ;

// Set up OGL
// Rotate up and down
glRotatef(player->angleUpDown, 1.0f, 0.0f, 0.0f);
// Rotate left and right
glRotatef(-player->direction, 0.0f, 1.0f, 0.0f);

// Move camera to world
if(player->bMoved) {
}
else {
glTranslatef(-playerX, -playerY, -playerZ);
}

for(int x = tx - VIEW_RANGE_X; x < tx + VIEW_RANGE_X; x++) {
float fx = (float)x;
for(int z = tz - VIEW_RANGE_Z; z < tz + VIEW_RANGE_Z; z++) {
float fz = (float)z;
if(x < 0) { x = 0; fx = 0; }
else if(x >= MAPWIDTH) { continue; }
if(z < 0) { z = 0; fz = 0; }
else if(z >= MAPHEIGHT) { continue; }

glPushMatrix();
glTranslatef(fx,0,fz);
glBindTexture(GL_TEXTURE_2D, *textures->getSprite(theMap->getTileAt(x,z,0)));
glColor3f(1.0f, 1.0f, 1.0f);
if(theMap->isSolidTile(x,z,0)) {
// Draw wall tile
glScalef(1.0f, 2.0f, 1.0f);
glCallList(solidList);
// The floor gets drawn anyway, let's continue
// While we could save some speed by not drawing the floor
// for solid tiles I want to expand to having 3D maps later on.
}
// Draw flat floor tile (ceilings later)
glCallList(floorList);
glPopMatrix();
}
}
}


Here's my display-list building code (it's frightening, please look away):
#define WALL_WIDTH 1.0f
#define WALL_HEIGHT 1.0f

void Map::generateDisplayList() {
//	Builds an OpenGL display list of our map using the rendering code
printf("INFO) Building OpenGL display lists (using quads)\n");

cubes = glGenLists(2);
glNewList(cubes, GL_COMPILE);

// ROOF
glNormal3f(0,1,0);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0f, WALL_HEIGHT, 0.0f);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(0.0f, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, 0.0f);
// WALL (FRONT)
glNormal3f(1, 0, 0);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0f, WALL_HEIGHT, 0.0f);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, 0.0f);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(WALL_WIDTH, 0, 0.0f);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(0.0f, 0, 0.0f);
// WALL (REAR LEFT)
glNormal3f(0, 0, -1);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0f, WALL_HEIGHT, 0.0f);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(0.0f, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(0.0f, 0, WALL_WIDTH);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(0.0f, 0.0f, 0.0f);
// WALL (REAR RIGHT)
glNormal3f(0, 0, 1);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, 0.0f);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(WALL_WIDTH, 0, WALL_WIDTH);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(WALL_WIDTH, 0, 0.0f);
// WALL (REAR)
glNormal3f(-1,0,0);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0f, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(WALL_WIDTH, WALL_HEIGHT, WALL_WIDTH);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(WALL_WIDTH, 0, WALL_WIDTH);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(0.0f, 0, WALL_WIDTH);
glEnd();
glEndList();

floor = cubes + 1;
glNewList(floor, GL_COMPILE);

glNormal3f(0.0f,1.0f,0.0f);
glTexCoord2f(0.0f, 0.0f);
glVertex3f(0.0f, 0, 0.0f);
glTexCoord2f(0.0f, 1.0f);
glVertex3f(0.0f, 0, WALL_WIDTH);
glTexCoord2f(1.0f, 1.0f);
glVertex3f(WALL_WIDTH, 0, WALL_WIDTH);
glTexCoord2f(1.0f, 0.0f);
glVertex3f(WALL_WIDTH, 0, 0.0f);
glEnd();
glEndList();
}


The important thing to notice out of the first source snippet is the glTranslate call in the map-rendering loop. My only assumption now is that there is some sort of rounding error with floating point precision (and I can't figure out a way to make them 'share' vertices). I attempted to change the texture filtering mode to GL_NEAREST like I read in a skybox-seams solution, but the problem persists there as well (and makes the textures ugly). I also attempted to "bloat" them a little bit by extending geometry. I haven't attempted offsetting textures, but I seriously doubt it's a texture issue. The only idea I have is to try and move the x- and z-components of the translation individually tile by tile rather than pushing and popping, but that will probably introduce the same problem. I've been banging on this for a few days, and I have absolutely no idea how to fix this.

##### Share on other sites
The seams are visible because each quad is being transformed by a different modelview matrix, and so rounding errors result in a slightly different position each time.

To fix it, avoid changing the modelview matrix at all while rendering the cubes, and generate the vertex positions yourself using a simple, consistent algorithm (like cube_x * 3.0f + 1.0f or something). Then adjacent vertices will have exactly the same final coordinates, and no seams will be visible.

##### Share on other sites
what might also help is using a tighter depth range, so where ever you call gluPerspective, set Z Near to no less than 1.0f and Z Far to around 100.0f. The z buffer is not linear, so changing Z far from 100 to 200 is like a 4x step the depth "range".

Cheers
-Danu

##### Share on other sites
Quote:
 Original post by silvermacewhat might also help is using a tighter depth range, so where ever you call gluPerspective, set Z Near to no less than 1.0f and Z Far to around 100.0f. The z buffer is not linear, so changing Z far from 100 to 200 is like a 4x step the depth "range".Cheers-Danu

I had Z-Near set to 0.01f before, so I put it up to 1.0f. That seems to have eliminated the appearance of seams, but now world geometry clips my HUD layer, and it also clips off early (so facing down a hallway allows you to see inside the walls).

Looking straight down only renders about half of the viewpoint (the content "in front" of the player).

I will have to figure out some sort of way to fix this so geometry is rendered further away from the viewpoint of the player, so I can use the depth range that fixes this problem without causing excessive clipping due to the player running into walls.

##### Share on other sites
Quote:
Original post by Ravuya
Quote:
 Original post by silvermacewhat might also help is using a tighter depth range, so where ever you call gluPerspective, set Z Near to no less than 1.0f and Z Far to around 100.0f. The z buffer is not linear, so changing Z far from 100 to 200 is like a 4x step the depth "range".Cheers-Danu

I had Z-Near set to 0.01f before, so I put it up to 1.0f. That seems to have eliminated the appearance of seams, but now world geometry clips my HUD layer, and it also clips off early (so facing down a hallway allows you to see inside the walls).

Looking straight down only renders about half of the viewpoint (the content "in front" of the player).

I will have to figure out some sort of way to fix this so geometry is rendered further away from the viewpoint of the player, so I can use the depth range that fixes this problem without causing excessive clipping due to the player running into walls.

If 1.0 to 100.0 dosn't work, scale them both back by the same factor (or scale your world up).

On the subject of the HUD layer, you should probably be changing projection matrix modes (to orthographic) for that anyway, and so you should set different depth buffer settings again there (not to mention, your HUD should probably have depth-buffering off).

##### Share on other sites
Quote:
Original post by Andrew Russell
Quote:
Original post by Ravuya
Quote:
 Original post by silvermacewhat might also help is using a tighter depth range, so where ever you call gluPerspective, set Z Near to no less than 1.0f and Z Far to around 100.0f. The z buffer is not linear, so changing Z far from 100 to 200 is like a 4x step the depth "range".Cheers-Danu

I had Z-Near set to 0.01f before, so I put it up to 1.0f. That seems to have eliminated the appearance of seams, but now world geometry clips my HUD layer, and it also clips off early (so facing down a hallway allows you to see inside the walls).

Looking straight down only renders about half of the viewpoint (the content "in front" of the player).

I will have to figure out some sort of way to fix this so geometry is rendered further away from the viewpoint of the player, so I can use the depth range that fixes this problem without causing excessive clipping due to the player running into walls.

If 1.0 to 100.0 dosn't work, scale them both back by the same factor (or scale your world up).

On the subject of the HUD layer, you should probably be changing projection matrix modes (to orthographic) for that anyway, and so you should set different depth buffer settings again there (not to mention, your HUD should probably have depth-buffering off).

That seems to have fixed it. Thanks, everyone!

Now just to debug the collision. [crying]

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627646
• Total Posts
2978384
• ### Similar Content

• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.
• By cebugdev
hi guys,
are there any books, link online or any other resources that discusses on how to build special effects such as magic, lightning, etc. in OpenGL? i mean, yeah most of them are using particles but im looking for resources specifically on how to manipulate the particles to look like an effect that can be use for games,. i did fire particle before, and I want to learn how to do the other 'magic' as well.
Like are there one book or link(cant find in google) that atleast featured how to make different particle effects in OpenGL (or DirectX)? If there is no one stop shop for it, maybe ill just look for some tips on how to make a particle engine that is flexible enough to enable me to design different effects/magic
let me know if you guys have recommendations.
• By dud3
How do we rotate the camera around x axis 360 degrees, without having the strange effect as in my video below?
Mine behaves exactly the same way spherical coordinates would, I'm using euler angles.
Tried googling, but couldn't find a proper answer, guessing I don't know what exactly to google for, googled 'rotate 360 around x axis', got no proper answers.

References:
Code: https://pastebin.com/Hcshj3FQ
The video shows the difference between blender and my rotation:

• By Defend
I've had a Google around for this but haven't yet found some solid advice. There is a lot of "it depends", but I'm not sure on what.
My question is what's a good rule of thumb to follow when it comes to creating/using VBOs & VAOs? As in, when should I use multiple or when should I not? My understanding so far is that if I need a new VBO, then I need a new VAO. So when it comes to rendering multiple objects I can either:
* make lots of VAO/VBO pairs and flip through them to render different objects, or
* make one big VBO and jump around its memory to render different objects.
I also understand that if I need to render objects with different vertex attributes, then a new VAO is necessary in this case.
If that "it depends" really is quite variable, what's best for a beginner with OpenGL, assuming that better approaches can be learnt later with better understanding?

• Hello all,

On my Windows 7 x64 machine I wrote the code below on VS 2017 and ran it.
#include <glad/glad.h>  #include <GLFW/glfw3.h> #include <std_lib_facilities_4.h> using namespace std; void framebuffer_size_callback(GLFWwindow* window , int width, int height) {     glViewport(0, 0, width, height); } //****************************** void processInput(GLFWwindow* window) {     if (glfwGetKey(window, GLFW_KEY_ESCAPE) == GLFW_PRESS)         glfwSetWindowShouldClose(window, true); } //********************************* int main() {     glfwInit();     glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);     glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);     glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);     //glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE);     GLFWwindow* window = glfwCreateWindow(800, 600, "LearnOpenGL", nullptr, nullptr);     if (window == nullptr)     {         cout << "Failed to create GLFW window" << endl;         glfwTerminate();         return -1;     }     glfwMakeContextCurrent(window);     if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress))     {         cout << "Failed to initialize GLAD" << endl;         return -1;     }     glViewport(0, 0, 600, 480);     glfwSetFramebufferSizeCallback(window, framebuffer_size_callback);     glClearColor(0.2f, 0.3f, 0.3f, 1.0f);     glClear(GL_COLOR_BUFFER_BIT);     while (!glfwWindowShouldClose(window))     {         processInput(window);         glfwSwapBuffers(window);         glfwPollEvents();     }     glfwTerminate();     return 0; }
The result should be a fixed dark green-blueish color as the end of here. But the color of my window turns from black to green-blueish repeatedly in high speed! I thought it might be a problem with my Graphics card driver but I've updated it and it's: NVIDIA GeForce GTX 750 Ti.
What is the problem and how to solve it please?

• 10
• 12
• 22
• 13
• 33