|
|
|
This thread is locked; no one can reply to it.
|
| [OpenGL] Cube drawing overlaps itself... but not others. |
|
Chris Katko
Member #1,881
January 2002
 |
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"} 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. 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. -----sig: |
|
Thomas Fjellstrom
Member #476
June 2000
 |
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
Member #562
July 2000
 |
The easiest way to check if it's a backface issue, as Tomasu mentioned, is to disable backface culling. __________________________________________________ |
|
Chris Katko
Member #1,881
January 2002
|
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"} 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"} Thanks everyone! -----sig: |
|
Mark Oates
Member #1,146
March 2001
 |
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
Member #1,881
January 2002
|
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. -----sig: |
|
Mark Oates
Member #1,146
March 2001
|
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. -- |
|
Arthur Kalliokoski
Second in Command
February 2005
 |
I've also seen the same type of problem with the Nouveau driver, if you're on linux. They all watch too much MSNBC... they get ideas. |
|
Chris Katko
Member #1,881
January 2002
|
{"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"} 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"} 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. 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. -----sig: |
|
Thomas Fjellstrom
Member #476
June 2000
|
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
Member #1,146
March 2001
|
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
Member #1,881
January 2002
|
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. -----sig: |
|
Thomas Fjellstrom
Member #476
June 2000
|
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. -- |
|
|
