Rendering Problem

We are developing a CAD like software for PCB design related problems. We have imported the text file exported from the PCB softwares in our first step. In our project, we are displaying the imported text file in a image using the OpenGL API functions. The design gets rendered successfully. But the problem we are facing is…, while it is in smaller size, some areas of the design is not visible to the viewer, (particularly lines). If we are zooming in, then it is visible. We dont know how to solve it. We are using orthographic projection. Please help us to solve this problem. If we use to draw in LINES using glpolygonmode, then the problem gets solved… But while zooming in, the PCB traces are visible as the polygons which filled in as lines instead of solid fill appearance… so to solve it we use solid filled polygons…

This is a sampling problem.

Basically when your traces are less than a pixel then there is a chance that they will not be rasterized if drawn as filled solids.

One solition is to use antialiased primitives. Since supersampling only moves the problem in scale it is only a partial solution.

Correctly weighted antialiased polygon rendering is the way to go here.

Since you have a 2D non zbuffered problem this should be relatively easy.

Use glEnable(GL_POLYGON_SMOOTH) and glEnable(GL_BLEND) with a glBlendFunc(SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) and you’ll see an immediate improvement with degenerate polygons but not a complete solution.

To truly fix this and all the antialiased blended cracks you probably now see you need to go with a saturate alpha algorithm and you need to sort the traces correctly in depth. Rendering the nearest traces first, and finish by drawing your background color behind if it’s not black that you want.

You need destination alpha buffer, start with black cleared screen and cleared alpha.


As per my private message, please disable the zbuffer when doing this.

Read my post carefully, there is detail in the text of the thread you may want to pay attention to.

I assure you that this is the definitive answer, however graphics cards have finite subpixel precision that will affect anti-alias weighting a.k.a. subpixel fragment alpha coverage. This is the limit of the technology you use unless you want to render to higher resolution and shrink down and you’d probably be tiled then.

Once again, the post I have given you is the best answer you’ll get.

You could fill AND draw outlines or do a thinkness test and switch between but that would be lower quality than my proposal and take smarter software. It would avoid the limit of subpixel precision which is a hardware dependent variable, I doubt that’s your problem though unless your lines are REALLY degenerate.

Again, zbuffer must be disabled.

Depth-testing was ON here??? That could surely explain a thing or two - drawing a flat PCB and then placing coplanar (!) traces on it.

However, should drivers+hardware work to spec (they don’t always do), that could be taken care of by PolygonOffset, obviously.

Dorbie: I’m not sure quality as such is really a factor here. Seems OP is more interesting in having PCB traces not “disappear” visually when zooming out.

I just came to think of yet another option, that actually might be simpler for OP to do:

When starting a zoom operation: Draw the PCB with all traces in ortho projection to a texture (for simplicity draw it to the backbuffer, and then copy it to a texture), and then simply use that texture as the face for the PCB (-quad, I hope).


The thing is i am not drawing the traces using GL_LINES. Because in opengl some linewidths are not supported. So i am drawing them as oblongs which is same as the width and height of the traces to be drawn.

Originally posted by Sangee:
The thing is i am not drawing the traces using GL_LINES. Because in opengl some linewidths are not supported. So i am drawing them as oblongs which is same as the width and height of the traces to be drawn.
Drawn both. So when polygons are too small, lines are still 1 pixel wide. As said Dorbie in a very professional manner.

Please listen to advices and post screenshots.

Okay, i will follow the above said advices and suggestions. I started working on it. Thank you dorbie, tamlin, and ZbuffeR.

With Regards,


    In our rendered image, say for example, there are ten lines of same width. But some of them are visible but some of them are not visible. Can anyone explain me why..? and suggest me some ideas.

If the width is smaller that one pixel size means, it will be invisible. But how some of them are visible, and some of them are not even though they all have the same width ?

Sangeetha. J

what’s it like in coimbatore?
draw the polygons using glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); then draw them again using glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);

Hi Knackered,

  We implemented your idea. Its working. All the lines are visible. But the lines are so thick. As we have to draw PCB traces, the width is of great importance. The gap between the two paralled traces will then be minimised due to the so much thickness. This problem arose due to drawing using two polygon modes (i.e., using GL_LINE and then GL_FILL). The code is as follows:
for(int polygonmode = 0; polygonmode < 2; polygonmode++)

		if(polygonmode == 0)
			glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
			glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);



You asked one question, “What’s it like in coimbatore?” I could not understand, Knackered… You asking about what…?

Thanking you for your reply,
Sangeetha. J

Originally posted by Sangee:
We implemented your idea. Its working. All the lines are visible. But the lines are so thick.
You don’t want to hear others telling you to antialias your geometry and you complain about aliasing effect? You are reaching your limits of your display, the resolution of current displays is not infinite. Buy a bigger one, with better resolution, with pixels so small you will not see them with the naked eye.
Dell D600, for example, has SXGA with 1400x1050 resolution and is only 14"! If I can afford it, everybody can, including you.