Sign in to follow this  
intrest86

Ugly Gaps between Tiles

Recommended Posts

Hey everyone, I was hoping someone could help me out with this: I just finished a routine recently that takes a map of a room (just a two-dimensional array of booleans where true=part of room) and then creates the vertex buffers for the floor and walls. Right now each column of the floor is 1 quad, just to keep life simple. However, there are some ugly white pixels that appear between each column of the floor. They aren't constant, they flicker back and forth as I rotate the model. They are also always on the right of the column (where right means positive x). I've checked the data used to initialize the buffers, and the vertices that are all in one seam have the same x values. Anyone have any idea what is going on? Are the coordinates not inclusive, maybe?

Share this post


Link to post
Share on other sites
My near and far planes are at 2 and 100, and I am using a 16bit Depth Buffer. Any ideas?

Edit: Well, I've found a hack to fix it by turning on AntiAliasing (Multisampling), but it seems like a really bad way to do it. If anyone has any ideas for how to really get reid of the gaps the right way, I'd be greatful.

Share this post


Link to post
Share on other sites
Just a shot in the dark: could there be something wrong with the textures?
In other words, do these artifact also appear on non-textured quads?

Share this post


Link to post
Share on other sites
The white dots are most likely your background (or whatever is behind the floor) peeking through. The effect is caused by your vertices not lining up exactly. The system the video card uses to fill polygons makes it very easy to see this effect. The only answer is to make sure the neighboring vertices are in exactly the same coordinates. That means the left side of one quad needs to be lined up exactly with the right side of one on it's left, and so forth.

Make your editor use snap values so your objects can be lined up on a grid. If each section of your floor is 32.2 in width, make sure the floors are spaced exactly 32.2 points away from each other.

Share this post


Link to post
Share on other sites
Quote:
Original post by WanMaster
Just a shot in the dark: could there be something wrong with the textures?
In other words, do these artifact also appear on non-textured quads?

I just gave it a try with Textured and Colored quads, and had the same problem.

Jiaa, I checked the values for each vertex of the floor after each was created (I lock the vertex buffer then right in the data). In that stage they are all completely lined up, ie all vertices on the left of column 1 have x=0, all on the right of column 1 and left of column 2 have x=.75, etc

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I ran into this when using a high resolution and attempting to line up square meshes that I laoded for example. The problem is there are slight inaccuracies/differences when each mesh is calculated, and then when it is translaoted and blitted to the screen, these inaccuracies show their ugly faces. The only method that Im aware of is using a SINGLE vertex buffer that doesn't redefine any of the points (all unique positions). Then build a single solid mesh from this. You can also create a routine to create a new SINGLE vertex buffer and hand it your mesh(es) and position, checking for any repeated points and utilizing the already define points with your added mesh(es) (just do a linear search for each piont and be lazy). Of course this becomes mroe complicated as you start using more textures, becaus eyou have to keep track of what polys need to be drawn as what texture.


BTW- this cracking and flickering effect is usually more apaprent in high resolutions than in low.

-Hope this helps

Share this post


Link to post
Share on other sites
Is that actually what is happening, though? Is your background color white? Or if the entire floor is missing, is white under it? If not, then it might be texture related.

If it isn't texture related, then I'm confused. The only time I've ever seen the gap problem was because the vertices were unwelded. If you use a vertex shader, you can test out a little hack to see if it fixes the problem. Here's some code for HLSL:

VertPos.x = int( VertPos.x + 0.5f );
VertPos.y = int( VertPos.y + 0.5f );
VertPos.z = int( VertPos.z + 0.5f );

Of course this will line them up on a 1.0x1.0 grid. If they are at smaller values, it will just make a mess of things and give you a bunch of gaps. Make sure you place this code before you multiply the vertex coordinates with your view or projection matrices.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I ran into this when using a high resolution and attempting to line up square meshes that I laoded for example. The problem is there are slight inaccuracies/differences when each mesh is calculated, and then when it is translaoted and blitted to the screen, these inaccuracies show their ugly faces. The only method that Im aware of is using a SINGLE vertex buffer that doesn't redefine any of the points (all unique positions). Then build a single solid mesh from this. You can also create a routine to create a new SINGLE vertex buffer and hand it your mesh(es) and position, checking for any repeated points and utilizing the already define points with your added mesh(es) (just do a linear search for each piont and be lazy). Of course this becomes mroe complicated as you start using more textures, becaus eyou have to keep track of what polys need to be drawn as what texture.


BTW- this cracking and flickering effect is usually more apaprent in high resolutions than in low.

-Hope this helps

Interesting. So, assuming this si the problem, the best solution would appear to be putting all of the used vertices once into a Vertex buffer, and then builing my triangle list with an Index Buffer? That is certainly possible to tie up the seams between the floor tiles.

I haven't mentioned this yet, ,but I am also getting the same seam problem between each column and the wall beside it (if there is one). It is technically possible to put the wall vertices also into the buffer (which basically means adding a second layer of vertices made up of the edge of the floor but heigher), but I'll have to play some games with texture coordinates. Is this advisable?

Share this post


Link to post
Share on other sites
Quote:
Original post by Jiia
Is that actually what is happening, though? Is your background color white? Or if the entire floor is missing, is white under it? If not, then it might be texture related.

If it isn't texture related, then I'm confused. The only time I've ever seen the gap problem was because the vertices were unwelded. If you use a vertex shader, you can test out a little hack to see if it fixes the problem. Here's some code for HLSL:

VertPos.x = int( VertPos.x + 0.5f );
VertPos.y = int( VertPos.y + 0.5f );
VertPos.z = int( VertPos.z + 0.5f );

Of course this will line them up on a 1.0x1.0 grid. If they are at smaller values, it will just make a mess of things and give you a bunch of gaps. Make sure you place this code before you multiply the vertex coordinates with your view or projection matrices.

Yes, the background is showing through in the gaps. I changed the color to red just to make sure, and all of the dots in the gaps did change color to red. I also used some Colored quads instead of Textured quads and had the same problem, so I think it is saf to rule out a texture problem. I'm only using the Fixed Function pipeline too.

Share this post


Link to post
Share on other sites
You shouldn't have to combine them. You should even be able to render each component of your map with a seperate render call and still not have this problem. The interpolation the renderer uses to fill the polygons with lines will remain constant as long as the vertices are exactly locked together. Unless it's a problem with your hardware, it has to be very small rounding errors in the vertices. Just one tiny 0.000001 can throw it off.

There's also another situation that can cause this that I've forgotten to mention. I think it's called T-junction. Instead of trying to explain, I'll show you. I threw some white quads under this so the dots were easier to see. Both of these snaps are from the exact same distance and angle. But one has them aranged in a different order. All of the quads are rendered seperately.

The first is a T-Junction, where even though the vertices line up perfectly, they are disconnected. One vertex ends up being the middle of a T edge shape, and that's very bad. The white dots are pretty clear. The second is how vertices should always be aligned:
Free Image Hosting at www.ImageShack.usFree Image Hosting at www.ImageShack.us

I've seen extremely professional games with terrible artifacts because of this. GTA: Vice City had a lot of city sections that must have been modeled seperately and joined with T-junctions, because it had a lot of artifact problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jiia
I've seen extremely professional games with terrible artifacts because of this. GTA: Vice City had a lot of city sections that must have been modeled seperately and joined with T-junctions, because it had a lot of artifact problems.

Thanks, there is actually a really good chance that I am having TJunction problems. Each of my columns is a single quad, and the can (and often are staggered). I'll try breaking up the columns so that each tile actually shares the same points as its neighbors. I guess I might just end up making it one quad per tile, since that is the simplest solution for breaking them up.

Share this post


Link to post
Share on other sites
Yay! The T-Junstions do indeed appear to have been the problem. I removed the function which was grouping tiles together into columns and just randered each seperately, and the artifacts were indeed completely gone.

I'm thinking that it is still a good idea to move it to using Index Buffers though. Now that I am using 6 vertices per tile (average of 3/2s per corner) and 6 overlapping vertices on average I would probably really benifit from dividing the size of the Vertex Buffer by six.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this