[OpenGL] Cube drawing overlaps itself... but not others.
Chris Katko

I've got this problem where a simple cube will overlap itself... but depth drawing appears to work and not overlap other cubes.

{"name":"609700","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/3\/6334eb720e88ed3730f47bc353d0f0d6.jpg","w":398,"h":324,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/3\/6334eb720e88ed3730f47bc353d0f0d6"}609700

It's a super weird effect. I kept thinking my cube drawing function was missing a face, or the face was positioned in the center but it's not.

Here's some code... I tried to remove non-graphics related stuff.

#SelectExpand
1 2int initialize() 3 { 4 if (!al_init()) 5 { 6 printf("Could not init Allegro.\n"); 7 return 1; 8 } 9 10 al_init_primitives_addon(); 11 al_install_mouse(); 12 al_install_keyboard(); 13 al_init_image_addon(); 14 al_init_font_addon(); 15 16 al_set_new_display_flags(ALLEGRO_WINDOWED); 17 al_set_new_display_flags(ALLEGRO_OPENGL); 18 display = al_create_display(SCREEN_WIDTH, SCREEN_HEIGHT); 19 20 if (!display) 21 { 22 printf("Error creating display\n"); 23 return 1; 24 } 25 26 al_set_target_bitmap(al_get_backbuffer(display)); 27 al_clear_to_color(al_map_rgb(0,0,0)); 28 29 glEnable(GL_DEPTH_TEST); 30 glDepthFunc( GL_LEQUAL ); 31 glHint( GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST ); 32 33 return 0; 34 } 35 36void set_camera_position() 37 { 38 glMatrixMode(GL_PROJECTION); 39 glLoadIdentity(); 40 glFrustum(-1.0, 1.0, -1.0, 1.0, 1.0, 40.0); 41 glTranslatef(camera.x, camera.y, -camera.dist); 42 glRotatef(camera.xangle, 1, 0, 0); 43 glRotatef(camera.yangle, 0, 1, 0); 44 glRotatef(camera.zangle, 0, 0, 1); 45 glMatrixMode(GL_MODELVIEW); 46 } 47 48 49void draw_cube() 50 { 51 52 glBegin(GL_QUADS); 53 54 // BOTTOM 55 glColor3f( 0.0, 1.0, 1.0 ); 56 glVertex3f( 0.5, -0.5, -0.5 ); 57 glVertex3f( 0.5, 0.5, -0.5 ); 58 glVertex3f( -0.5, 0.5, -0.5 ); 59 glVertex3f( -0.5, -0.5, -0.5 ); 60 61 // White side - TOP 62 glColor3f( 1.0, 1.0, 1.0 ); 63 glVertex3f( 0.5, -0.5, 0.5 ); 64 glVertex3f( 0.5, 0.5, 0.5 ); 65 glVertex3f( -0.5, 0.5, 0.5); 66 glVertex3f( -0.5, -0.5, 0.5 ); 67 68 // Purple side - RIGHT 69 glColor3f( 1.0, 0.0, 1.0 ); 70 glVertex3f( 0.5, -0.5, -0.5 ); 71 glVertex3f( 0.5, 0.5, -0.5 ); 72 glVertex3f( 0.5, 0.5, 0.5 ); 73 glVertex3f( 0.5, -0.5, 0.5 ); 74 75 // Green side - LEFT 76 glColor3f( 0.0, 1.0, 0.0 ); 77 glVertex3f( -0.5, -0.5, 0.5 ); 78 glVertex3f( -0.5, 0.5, 0.5 ); 79 glVertex3f( -0.5, 0.5, -0.5 ); 80 glVertex3f( -0.5, -0.5, -0.5 ); 81 82 // Blue side - BACK 83 glColor3f( 0.0, 0.0, 1.0 ); 84 glVertex3f( 0.5, 0.5, 0.5 ); 85 glVertex3f( 0.5, 0.5, -0.5 ); 86 glVertex3f( -0.5, 0.5, -0.5 ); 87 glVertex3f( -0.5, 0.5, 0.5 ); 88 89 // Red side - FRONT 90 glColor3f( 1.0, 0.0, 0.0 ); 91 glVertex3f( 0.5, -0.5, -0.5 ); 92 glVertex3f( 0.5, -0.5, 0.5 ); 93 glVertex3f( -0.5, -0.5, 0.5 ); 94 glVertex3f( -0.5, -0.5, -0.5 ); 95 glEnd(); 96 } 97 98void draw_cube_at(double x, double y, double z) 99 { 100 glPushMatrix(); 101 glTranslatef(-2.5 + x, 0.0 +y , 0.0 + z); 102 draw_cube(); 103 glPopMatrix(); 104 }

Most of this stuff is derived from the opengl.cpp and opengl2.cpp Allegro examples.

Thomas Fjellstrom

Check to see if you have the vertexes in the right order. I think the default is counterclockwise. But you can switch it with an opengl call.

StevenVI

The easiest way to check if it's a backface issue, as Tomasu mentioned, is to disable backface culling.

Chris Katko

Hmm, it really looks like a depth issue.

{"name":"609702","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4355f1e2f8bb08b90e8d977aca37be8.png","w":642,"h":505,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4355f1e2f8bb08b90e8d977aca37be8"}609702

All I did here was make the bottom face one unit cube lower (and change the color). They shouldn't be painting over everything.

[edit] Also, geez JPEG is a terrible format when dumping from mspaint.

[edit 2] replaced with PNG.

[edit 3] I just saw your post. I actually have disabled backface culling.

glDisable(GL_CULL_FACE);

To no avail.

[edit 4] Ah crap. Looks like I don't have a Z-buffer.

int depth = al_get_display_option(display, ALLEGRO_DEPTH_SIZE);
  if (!depth)
    printf("No Z-buffer!\n");
  else
    printf("Z-buffer %i-bits!\n", depth);

Says no Z-Buffer.

... Yep... here's the line that was missing: 

   al_set_new_display_option(ALLEGRO_DEPTH_SIZE, 16, ALLEGRO_SUGGEST);

{"name":"609703","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a6de1bc6193305e6480e724d9faf3025.png","w":642,"h":505,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/6\/a6de1bc6193305e6480e724d9faf3025"}609703

Thanks everyone!

Mark Oates

You should also clear the depth buffer before rendering the scene. al_clear_depth_buffer(1). 1 is the farthest, 0 is the closest, so clear to anything greater than (or equal to) 1. Probably do that after like, clearing the screen.

Chris Katko said:

Most of this stuff is derived from the opengl.cpp and opengl2.cpp Allegro examples.

Shame on you! You can do all that with Allegro's native functions. ;)

Chris Katko
Mark Oates said:

Shame on you! You can do all that with Allegro's native functions. ;)

Allegro's functions don't have the documentation that GL ones do. I'm still completely confused about when and where to use Allegro 5 functions verses OpenGL ones, and how to get back to Allegro 5 coordinates for drawing the overlay.

Simply pushing and popping matrices don't work, so either I need to save multiple ones (like projection and model, not just model), or Allegro changes something special I don't understand yet.

Mark Oates
Chris Katko said:

Simply pushing and popping matrices don't work, so either I need to save multiple ones (like projection and model, not just model), or Allegro changes something special I don't understand yet.

Each bitmap has its own projection. So if you create the backbuffer, and then create another sub-bitmap of the backbuffer. They will both have their own, separate projections but will draw to the same surface. 8-)

Arthur Kalliokoski

I've also seen the same type of problem with the Nouveau driver, if you're on linux.

Chris Katko

{"name":"609704","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/1\/217a9aa00ad4d8d0b9c02a5cc1b3cb8b.png","w":944,"h":793,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/1\/217a9aa00ad4d8d0b9c02a5cc1b3cb8b"}609704

Things are working, but I'm not entirely sure why things are so slow. Surely, a bunch of glBegin/glEnd's are going to be slower but I'm getting like ~23 FPS with this image. Each unit cube has their own begin and end. Perhaps it's because they're 128x128 textures each... but that shouldn't be too bad for a GeForce GTX 560 SE... I can run Fallout: New Vegas.

I'm wondering how much VBOs/vertex arrays will help, and if a move toward the modern pipeline will speed things up... but still... a 50x50 set of cubes is pretty pathetic... I used to run far higher when I was doing my Minecraft-in-space game years ago.

I am running in a VM, which slows it "somewhat" (and does remove features like AA), but I'm pretty sure my Minecraft game was also in a VM... maybe not... I don't remember it's been so long.

{"name":"O8DGS9c.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/4566f393bc13fff1dae8ab95cce0d64e.jpg","w":812,"h":638,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/5\/4566f393bc13fff1dae8ab95cce0d64e"}O8DGS9c.jpg

Mark Oates said:

Each bitmap has its own projection. So if you create the backbuffer, and then create another sub-bitmap of the backbuffer. They will both have their own, separate projections but will draw to the same surface. 8-)

That's a very confusion statement. How can a bitmap have a completely different projection from the global OpenGL stack?

Arthur Kalliokoski said:

I've also seen the same type of problem with the Nouveau driver, if you're on linux.

I've had some really crappy luck with them before as well. Lots of screen corruption issues.

Thomas Fjellstrom
Chris Katko said:

That's a very confusion statement. How can a bitmap have a completely different projection from the global OpenGL stack?

Allegro keeps track and switches back and forth iirc. Bitmaps are (by default) backed by a texture, and a FBO which gets you a completely separate render target so they may need a different projection than the display's projection.

Mark Oates
Chris Katko said:

Surely, a bunch of glBegin/glEnd's are going to be slower but I'm getting like ~23 FPS with this image.

Are you glBegin/glEnd for each square? That'll cost ya. Do it as one big prim and you can easily draw something with 100x more triangles.

Chris Katko

But you can't do texture switches inside those, right?

Maybe I don't need those and I can just use a normal mesh with a single tiled texture.

I guess I could also use one texture with multiple tiles and specify the UV coordinates... though I'm not sure if they'd bleed into each other.

Thomas Fjellstrom
Chris Katko said:

though I'm not sure if they'd bleed into each other.

Atlasing is a very common thing. There is one thing that can cause bleeding (some filtering or other fancy thing), but the solution to that is to just add some transparent (or solid white/black) pixels between the individual textures.

Thread #615647. Printed from Allegro.cc