I’ve been working in a 3D engine. It works pretty well by now but there is something I don’t know how to fix.
When I move through the world, weird white lines appear and diappear on the edges of some objects. You can see what I mean here: http://dokidoki.dreamers.com/weirdlines.htm
Anyone has seen this problem before?
Any ideas?
At first, I thought it could be a texturing problem. I am importing ASE files from MAX. But I changed it and the problem was still there.
I don’t reckon it’s a depht buffer precision problem because the lines appear when I’m far away from the object as well as when I’m near it.
What do you think is the cause of this problem?
Thanks!
-nemesis-
[This message has been edited by nemesis (edited 07-10-2002).]
Probably the narrow back side of the wall shining through at the edge where both polygons (left side and back side) are supposed to have the same z-buffer values.
This would be a typical depth test case for first comes, first served (depth func GL_LESS).
Do you have backface culling enabled?
Could also be stitch marks if the geometry is not using the exact same vertices, but for a box, that’s unlikely.
Or a texture clamp error blending the texture border color.
I think the vertices on that edge are shared by both faces. Unless 3DMAX have made something strange while exporting to ASE file.
That think about texture border… I’ve no border defined. I’ve tried to change the default border color with:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BORDER_COLOR, red_color);
but nothing happens.
For more info… I’m using multitexturing with lightmaps on a GeForce2 PRO. Do you reckon the lightmaps could be the problem?
Originally posted by nemesis: I think the vertices on that edge are shared by both faces. Unless 3DMAX have made something strange while exporting to ASE file.
Probably nothing to do with your problem, but it’s definately worth checking to see if max isn’t producing duplicate verts with slightly different float values…just pass through your vertex arrays comparing each one against all the others to see if there are any that are duplicated (roughly), with all the same other attributes (texcoords etc.).
I added a check like this for my importers, and you’d be surprised how wasteful max exporters can be…
OK if you have backface culling on then that polygon is in twice pointing in both directions
This is zfighting between the rear polygon facing in and the side polygon facing out.
If, as you say backface culling is on then the white fragment is from some bogus internal geometry which duplicates the rear face pointing in the wrong direction.
Go fly inside the object and look out. Then go blame your modeller.
I’ve already checked the model and it is ok.
I’ve found out that the problem is caused by the lightmaps because when I turn off the lights it works well. In this case I use a default lightmap with ambient light.
Maybe is something about packing all the lightmaps in a single texture… but I don’t know why it doesn’t work, I’m not mipmapping them.
Any ideas will be welcome!
I’ve got 10 euro here that says you’re seeing bilinear filtering artifacts since you have no extra padding around your light map polys If you have the lightmaps of two different polys packed adjacent to eachother in a single texture, then bilinear filtering will sample from the neighbour polygon’s lightmap which will give incorrect results. This has been discussed extensively here in the past, do a search for “light map padding” or “light map filtering” and I’m sure you’ll find many excellent threads.
Nearly, Harsman!
I’m using GL_NEAREST. Maybe it is why sometimes lines appear and sometimes not. I’ve changed to GL_LINEAR and now lines appear always but a little blurred.
Do you think I should made my lightmaps a little bigger so that OpenGL don’t get the wrong pixel? Or is there an easier solution?
Originally posted by nemesis: Yes, I’ve multiple lightmaps in one texture but I’m not using mipmaps with them for that very reason.
OK, thats why I was asking. If you pack multiple lightmaps into a single texture, there are 2 (that I know of) areas where you can run into problems.
The first is (as harsman said) that if you dont put padding around the lightmaps you can get bleeding. What you need to do is, for each lightmap in the texture, go around it’s border and stretch each border texel out an additional texel. The other way to get a similar effect is to adjust your tex coords in 1/2 texel (the downside of this way is that is will slightly change how it is drawn). Of course, if your modeller is the one generating the lightmaps and texcoords, you might have a problem fixing this. Im not sure how you would handle such a thing.
The second thing that can cause these errors is mipmapping. As you say, you dont do mipmapping, so it “shouldn’t” be a problem. However, I think there might be hardware out there that does mipmapping automatically for you whether you ask for it or not (but I’m not positive). If there hardware does generate the mipmaps automatically, then what you may need to do is used the EXT_texture_lod_bias extension to FORCE the hardware into always using the first mip level.
I’ve just fixed the problem adding padding around the lightmaps duplicating the edge pixels. They are a little bigger now, but the artifact has eventually disappeared.
If you have the lightmaps of two different polys packed adjacent to eachother in a single texture, then bilinear filtering will sample from the neighbour polygon’s lightmap which will give incorrect results. This has been discussed extensively here in the past, do a search for “light map padding” or “light map filtering” and I’m sure you’ll find many excellent threads.