Jump to content
  • Advertisement
Sign in to follow this  
pauljan

OpenGL Seams on adjacent cubes

This topic is 5104 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, In the image below I took 16 cubes and placed them in a 4x4 grid. OpenGL lighting is on, causing the sides of the cube to have a visibly distinct color from the top face. As you can see, seams appear where the color of those sides bleeds through to the surface. Any ideas? As long as the vertice coordinates are all the same and there are no t-junctions or whatsoever, I thought seams like this were not an issue (with the API guarantee that two lines with the same start and end coordinates are rasterized identically). Additional notes: The cubes are rendered in world coordinates (i.e. no glTranslates in between rendering two cubes), and as far as I can tell the vertice coordinates are truely identical. Thanks for any insight you guys can share with me!

Share this post


Link to post
Share on other sites
Advertisement
Problem could be a depth buffer that can't hold precise value's.


static PIXELFORMATDESCRIPTOR pfd = // pfd tells windows how we want things to be
{
sizeof(PIXELFORMATDESCRIPTOR), // Size of this pixel format descriptor
1, // Version number
PFD_DRAW_TO_WINDOW | // Format must support window
PFD_SUPPORT_OPENGL | // Format must support OpenGL
PFD_DOUBLEBUFFER, // Must support double buffering
PFD_TYPE_RGBA, // Request an RGBA format
bits, // Select our color depth
0, 0, 0, 0, 0, 0, // Color bits ignored
0, // No alpha buffer
0, // Shift bit ignored
0, // No accumulation buffer
0, 0, 0, 0, // Accumulation bits ignored
16, // 16Bit Z-Buffer (Depth buffer)
0, // No stencil buffer
0, // No auxiliary buffer
PFD_MAIN_PLANE, // Main drawing layer
0, // Reserved
0, 0, 0 // Layer masks ignored
};







Here, the Z-buffer can hold 2^16=65536 (2 bytes) different values.
I think your Z-buffer is set to 8 bits (1 byte). So the Z-buffer can only hold 256 different values.

If the depth of a pixel is compared to a new depth
that is nearly the same but just a little bit further
the bleeding occurs.

Solutions are:
1)setting the znear and zfar of the clipping volume closer to each other.
gluPerspective(double fovy, double aspect, double zNear, double zFar))
2)create a Z-Buffer with more bits (i think 16 should be fine)

If the problem still exists, it could be you have a bad graphics card.

(I have the same problem, and setting the Z-Buffer to 16 bits makes no difference. I guess a geforce2 became a bit prehistoric)

hope this helps

[Edited by - Kwak on November 21, 2005 2:28:10 PM]

Share this post


Link to post
Share on other sites
Thanks for the input. However, I already fiddled around with the near (and far, but near obviously has a bigger impact :)) clipping planes and it didn't change things at all. About graphics cards: the application has several users suffering from this issue, and it occurs on both my development machines (Geforce 2 and Geforce 6600 with latest drivers installed), so I think I can safely rule out "bad graphics card".

Even theoretically I don't see a compelling reason why those lines shouldn't be rendered. Why the edges of the cube be rendered in the color of the top face, and not the side?

I am stumped. Again, any input on this issue would be most appreciated!

Share this post


Link to post
Share on other sites
Well just a thought, have you tried an ATI card? Because while openGL can promise anything it wants, its up to ATI and NVIDIA to implement it in its drivers, and it very well could be that NVIDIA skimped on that (i dont know how likely that is) just something to take into consideration

cheers hope that helps
-Dan

Share this post


Link to post
Share on other sites
Isn't this just perfectly normal Z-fighting? It'll happen whenever you have two overlapping polygons close to each other in the Z direction (in this case, infinitely close at the edge). Polygon offsets may help, or possibly changing the draw order; but the best solution is to just not draw the side faces that shouldn't be visible.

Share this post


Link to post
Share on other sites
If you want to check that the vertices are truly identical, == should evaluate to true (it'll be false even if they're little bit different). For example 0.01==0.1*0.1 is false on my compiler.

I'd guess that they're not exactly the same (you calculate the matching vertices slightly different). May also be from converting floats to doubles (I don't know if the lower bits of the double have to be changed when converting a float)

Share this post


Link to post
Share on other sites
The only way I was able to reproduce that problem was by setting the polygon mode to line, drawing it, change the polygon mode to fill and redraw it. You can see it just drawing a single quad that way. If the line is horizontal or vertical then you don't seem to get it, but if it's at an angle you see it.

Share this post


Link to post
Share on other sites
First of all, thank you guys for all the input!

Ademan555: Not a bad suggestion, but I am pretty sure at least one of our users experiencing these problems is on ATI. Also, I have come to understand the 'issue' at hand here is completely natural, so I would expect it to happen on ATI cards as well.

Cocalus: I doublechecked this by using integer values (so no precision issues) for the vertices... oh, and I also welded the vertices just to make sure. No difference there. I am pretty much positive it is no precision bug :)

Fingers_: I believe you are right. Polygonoffset is not a solution, as I am dealing with polygon soup (I am guessing you/Eitsch meant using a different polygon offset for the top faces to make sure they are rendered over edges the side faces). Not drawing the inside faces is definitely the ultimate solution, but we are talking a generic 3D modeler here: it's artistic users deciding to weld cubes together, not me :) However, we'll probably be offering some "fix geometry issues" functionality in the future, to automatically remove such inner faces.

LilBudyWizer: Yep, the effect is dependend on camera angle. Which makes perfect sense if it's just natural z-fighting due to edges being infinite close to each other.

Share this post


Link to post
Share on other sites
I don't know what you call z-fighting. I always assumed that what people meant by that was rounding errors on the depth values. That isn't what I saw. You can turn the depth test completely off and still see it. Line mode includes pixels in the edge that are not part of the polygon in fill mode. It's more that the pixel is in the wrong place than that it has the wrong depth.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!