Polygon seems/tears. Please help.

Hello,

My engine is practically complete, from vertex buffer objects, fast 2d to pixel shader post-fx…yet, i’m still plagued with what I thought was a problem gone with the age of ps1!

My polgons have white seems. Not everywhere, but randomly popping up in the same places.

Some models are worse than others. But it just ruins the whole engine as you can imagine, and nothing I can find seems to indicate what causes this. The closest problem seems to be z-fighting…but there is no underlying geo, it occurs at polygon edges only.(I.e never within a poly)

The engine has pipelines for display lists/vertex buffer objects and vertex arrays.

Also, less importantly for now, I’d love it if one of you gurus could give me a few tips on good mip-mapping. My textures still flicker at a distance, appearing to alias the same as a polygon model would.

I’ve tried lowering/increasing near/far z-depth, to no avail.

Any help/tips would be great.

I have a geforce 5-5600xt btw, I think soft-modded to a quadro. I may have bodged that up, but I don’t have this problem with any game, including graphic intensive ones like knights of the old republic, details set to high.

T-junctions ? These would make small dots appear, not full seems, but that’s the first thing that came to my mind when i read your description. Is white your background color by any coincidence ?

Y.

Yeah, though the scene does have geo behind it in some cases(Far behind it, it’s a map.)

But you’re right, it’s white dots. I looked up on t-junctions and tried edge_clamp etc, and not only did it ruin my mapping, the dots were still there…might be something else.

Btw just checked, by turning the background color to red and sure enough the white dots were now red, so it’s definitely pixel gaps.

Any ideas why both clamp modes both screw up texturing and don’t prevent the ‘t-junction’?

Texture clamp modes have nothing to do with t-junctions. T-junctions occur when adjacent polygons share a mathematical edge but, due to the process of rasterization, deviate slightly from this ideal line. They can be fixed by inserting vertices at the intersections.

    
       
*---------------------*
|                     |
|          A          |
|                     | 
*----------*----------* 
|          |          |
|          |          | 
|    B     |     C    |
|          |          |
*----------*----------*
 

In this case, polygons B and C are okay, but we need to add a vertex to A at the “T”.

what do you need to know about mipmapping. All you do is create a texture half the size of the oringal continuously until you get to 1’1’ glu library has a function to help you out
>>gluBuild*DMipmapLevels

Q, thanks for the tip. Any idea how (or a link to a tutorial) to ‘fix’ any mesh? Since it’s loading outside media, it would have to be some sort of function that just takes a unfixed mesh and then generates a fixed one. Question is, is there an easy way of finding out where you need to place these verts in code? (I’m not the greatest math…guy…)

Grim, yeah I use that. But for example if I have a texture that is a reflection, and goes from bright gold to 0,0,0 in the space of a pixel, as the camera moves away this ‘transistion’ alias like the edge of a poly…flickering.

The mip-mapping does solve some of the general probs, so it’s working…just not nearly as nicely as most engines.

Would it be better to generate my own mip map levels with filters?

I don’t know of any tutorials on the subject (I haven’t researched this). You could try digging around in some open source tools/editors/engines; you could certainly find some working code.

The idea is pretty simple; the tricky part is inserting the vertices in the right order, maintining the desired winding order.

Here’s a quick sketch of the steps involved:

First, let’s assume you have an array of all polygons in your mesh. Let’s also assume that you have an array of all unique polygon vertices, call it “verts”. An edge is any 2 successive polygon vertices in clockwise order.

fix polys:
for each polygon p
for each edge e in p
fix edge e

fix edge:
for all verts v
if v is on the line containing e
and v is between e start and end
then insert v into e in order from start

Really, all you’re doing is looking for the Ts, that is, a vertex resting in the middle of some edge. The tricky part, the insertion, can be achieved by comparing the distance of v along the edge in question; if it’s greater than the inserted v’s distance, then it comes after, else before.

insert v:
for all currently inserted verts test in e
if length(v - e_start) is less than length(test - e_start)
then insert v here

I hope this makes some sense.

if this is more of a game engine, and artists create the geometry for you, their tools would often be a lot easier to fix those T junctions. Like 3dsmax for instance has a STL modifier which will find gaps like this.
Of course this is no “code” solution, but if you or anyone actually builds the geometry data by hand, it’ll be much easier if she/he fixes those things.
Sometimes a bad model is just a bad model, I think it would be too much work if the code would need to fix all this, when its just the modeller who could take care of it.
Though if your data is generated different, then it would need a code solution.

This isn’t something really simple like having polygon smoothing switched on is it?

I would rather say that the problems comes from mipmapping.

Btw just checked, by turning the background color to red and sure enough the white dots were now red, so it’s definitely pixel gaps.

This is wrong. If you trashed your 2x2 or 1x1 mip level (and nVidia drivers used to do this for you), they’ll display the active color, and that could be the background color in your case. You should rather try to render a texture in background.

Your problems seems like mip mapping trashing to me

SeskaPeel.

Thanks for the little tut Q. I think I get it. :wink:

As for it being the mesh in question, it could be. It was converted from a bsp into a normal mesh(By a 3rd party app, not the engine)

I’m not sure i know what you mean by mip-map thrashing? It doesn’t appear to affect an whole level, as it’s only ever a pixels at the edge of a poly.(they almost form lines in really bad parts)

Codocop,
we experienced exactly these “line near the edges” problems. And … it was a mipmap problem. again, it was solved driver newer version.
What drivers are you using ?

SeskaPeel.

As for it being the mesh in question, it could be. It was converted from a bsp into a normal mesh(By a 3rd party app, not the engine)
BSPs are notorious for introducing t-junctions. If your 3rd party app didn’t fix them, then your maps will likely be riddled with them.

Some of the big engine houses (Id, Epic, Valve) use their own tools on their own maps (created from their own editors) to fix this stuff. It’s a very common problem.

Search for mesh repair tools. Some utilities like tristrippers have a stage to repair meshes (and this is one of the things they can fix), issues like this are increasingly common/important because operations like shadow volume extrusion require watertight geometry and the problems you see can be amplified if not solved.