So like, can anyone explain this to me? (OpenGL issue)

[N64vSNES]

So I tested Crafter on my old PC to make sure it's not draining too much performance and yeah I've noticed a problem with it:




Look closely and you can see white pixels along the edges of the cubes. It's not as bad on my new PC but when it does happen it can come in huge lines straight across the screen. It's rare though but it does happen.

It's not that big of a deal on my newer PC but after testing it on something less capable I know it needs fixing.

The map is getting drawn as a huge mesh between begin/end OpenGL calls, I'm using GL_NEAREST to filter the textures, using GL_LINEAR doesn't help any it just makes the block textures leak into each other. Also I've noticed that they are white because I last called glColor3f(1,1,1) so if I change it to glColor3f(1,0,0) then they would flicker red.

Other than that I wouldn't know what details to go into. It's a bizarre issue.

Any suggestions? If you think I haven't gone into enough depth which I highly doubt I have then please do say, I just really wouldn't know what to go into for a problem like this.

Thanks.

[EccentricDuck]

I'm pretty sure that the issue stems from rounding errors in the geometry. You have these separate meshes that are perfectly lined up, but when the projection calculations are done you get some artifacts from rounding which leave slight discrepancies between those once perfectly aligned edges. I'm not entirely sure what the best solution would be to fix it in OpenGL, but anything to blend the separate meshes together is worth a shot (you said GL_LINEAR didn't work?).

[N64vSNES]

I'm pretty sure that the issue stems from rounding errors in the geometry. You have these separate meshes that are perfectly lined up, but when the projection calculations are done you get some artifacts from rounding which leave slight discrepancies between those once perfectly aligned edges. I'm not entirely sure what the best solution would be to fix it in OpenGL, but anything to blend the separate meshes together is worth a shot (you said GL_LINEAR didn't work?).

I see, well it's drawn as a single mesh but each polygon would actually be considered as a single quad. I'm not sharing any of the vertex's.

GL_LINEAR?....Well I'll let you be the judge of that:

[bnpph]

Try making the size of the cubes slightly larger so they overlap.

[N64vSNES]

Try making the size of the cubes slightly larger so they overlap.

Still no difference.

You can see the textures are actually starting to get in the way of each other because they're overlapping so much, but they still have that ugly border.

I think this could actually be because the blocks are all clipped from the same image. Using GL_LINEAR has always made other frames/tiles or whatever leak into each other.

If this is the case, there is no way I could split it into individual images, that would affect the performance too drastically. ( Switching texture for each face of each cube )

[EccentricDuck]

I see, well it's drawn as a single mesh but each polygon would actually be considered as a single quad. I'm not sharing any of the vertex's.

Just to clarify, but are you saying you're using a single continuous mesh that covers multiple quads, or a single mesh that is applied individually to a bunch of quads?

From what I understand, the projection calculations are done on the geometry to display the polygons in the right places relative to your screen, and after that the way the textures are displayed is calculated (even though the textures have been mapped to the geometry before drawing).
Assuming each quad has the projection calculations applied independently of other geometry: those calculations would have to be done individually for each quad since each has a unique projection geometry after the projection calculations have run through.

I recall seeing something like this when playing around with primitives. I wonder if vertex sharing would solve it (it may even help to optimize the draw call slightly since you'll be acting on both fewer vertices and longer stretches of shared geometry so it's more streamed). If the vertices were shared, and you had surfaces rendered all in one go, I think what you'd get is one big polygon mesh after the projection calculations have gone through - then the texture would be applied to it (either in one go if it was a giant mesh, which I'm assuming it's not, or continuously repeated). That's my 2 cents.

[qpHalcy0n]

You need to take bnpph's advice and make the geometry overlap slightly. You've got here a pretty classical problem w/ co-linear geometry becoming victim of floating point roundoff error due to the non-linearity of perspective projections. This is evidenced by the fact that your clear color (red) is showing through. Switching texture filtering modes will not help as the fragment will have already been transformed before it is lit, it will simply change how the texture is applied to the fragment since the area of the polygon will either be larger or smaller than the source image. You can't "invent" pixels (keeping it VERY simple here :P) is what i'm saying....the geometry has already been transformed at this point.

It appears that overlapping the geometry has INDEED solved the problem, but you've run into another. Z-fighting. Z-fighting appears distinctively different which is what I believe I'm seeing there. Now you have overlapping geometry fighting for precision in a depth buffer with very limited precision. You can gain precision by either increasing the depth buffer precision, bringing the near plane further away from the camera (lots of precision is wasted very close up), or by investigating polygon offsets. This will allow you to fudge the value that gets written into the z-buffer. Yes its a complete hack, but what in game development isnt?

Stitching the shared vertices together is also a possible solution to this problem. It would require some pre-processing on your part but has the potential of being a better solution.

[N64vSNES]

Thanks for the advice guys, I'm going to try all of this out as soon as I can.

But just to clear things up my process is:

Code: Select all

glBindTexture(GL_TEXTURE_2D, daTexture);
// Loop through the blocks
glBegin(GL_QUADS);
for(;;) {
    for(;;) {
         for(;;) {
            // Draw the cube
         }      
    }
}
glEnd();

Sharing each vertex I'll most definitely get around to, if Crafter is supposed to be better at anything it has to be the performance

It appears that overlapping the geometry has INDEED solved the problem, but you've run into another. Z-fighting. Z-fighting appears distinctively different which is what I believe I'm seeing there. Now you have overlapping geometry fighting for precision in a depth buffer with very limited precision. You can gain precision by either increasing the depth buffer precision, bringing the near plane further away from the camera (lots of precision is wasted very close up), or by investigating polygon offsets. This will allow you to fudge the value that gets written into the z-buffer. Yes its a complete hack, but what in game development isnt?

It doesn't look like it has solved the problem, I can see what you mean with the Z-fighting problem but it looks like it's just made the first problem a little less noticeable. The reason why the Z-fighting problem exists is because I made them overlap so much as at first it wasn't making a difference.

[N64vSNES]

Sorry to double post but:



The bright yellow shows that changing the texture filter to GL_LINEAR didn't solve problem

[bnpph]

Is your texture part of a texture atlas?
You might be seeing the edges of other surrounding textures.
Try reducing the bounding box of your texture coordinates.

[qpHalcy0n]

You need to first determine what the issue really is. It VERY much looks like a T-junction issue.

Disable texturing and see if the issue still appears.

[N64vSNES]

You need to first determine what the issue really is. It VERY much looks like a T-junction issue.

Disable texturing and see if the issue still appears.

Okay so this T-junction stuff is completely new to me, I'm going to do a bit of searching about what that is. I just tried disabling texturing and it works perfectly, not so much as a single unwanted pixel.

Is your texture part of a texture atlas?
You might be seeing the edges of other surrounding textures.
Try reducing the bounding box of your texture coordinates.

I tried this at first, and again with GL_LINEAR as the texture filter. It doesn't seem to be making a difference

EDIT:


Looks like I didn't look close enough, although it's much better without textures.

Since it's worse on my old PC do you think performance could be affecting this?

[EccentricDuck]

It appears that overlapping the geometry has INDEED solved the problem, but you've run into another. Z-fighting. Z-fighting appears distinctively different which is what I believe I'm seeing there. Now you have overlapping geometry fighting for precision in a depth buffer with very limited precision. You can gain precision by either increasing the depth buffer precision, bringing the near plane further away from the camera (lots of precision is wasted very close up), or by investigating polygon offsets. This will allow you to fudge the value that gets written into the z-buffer. Yes its a complete hack, but what in game development isnt?

Very cool, I always wondered what caused polygons on the same plane to sometimes flicker in and out for the top visible layer.

[qpHalcy0n]

You've more than likely got both problems running at once, which is just EXCELLENT for you. The T-junction problem is pretty well documented and will definitely require you to sit down and re-think your approach to rendering your world. It's definitely more than I'm willing to go into here.

The texture issue may also be biting you in the ass. Be sure that you have alpha blending disabled for opaque geometry as if you have a large texture that contains an alpha channel along edges you may indeed be inappropriately sampling beyond the edge of the texture. This is true if you're using a texture atlas as was alluded to earlier. I say that it could be in the alpha channel simply because its the clear color that's bleeding through.

However, I think most of your issue here is t-junction. So, look into it and see what you come up with. In general its never a good idea to render discrete pieces of geometry that share edges separately, ESPECIALLY if they share a texture map without some form of management. The only way the hardware can GUARANTEE that the edge will resolve perfectly is if the geometry is convex. In the case of discrete cubes this can not be guaranteed.

[TheBuzzSaw]

qp, is this not the same issue I had with my terrain? Using GL_CLAMP_TO_EDGE instead of GL_CLAMP fixed mine. Just a thought.