View Full Version : rasterization rules of polygons
09-19-2001, 05:08 PM
I know that opengl has rules about how a polygon is rasterized, but it might be useful if I could change those rules.
One of the rules is that when 2 polygons (side by side) have an identically positioned edge, then every pixel that lie about that edge will be rendered to such that there will be no seam. (the wording of the specs are better, I'm sure)
Unfortunatly, not many hardware vendors follow that rule which makes my life a lot harder.
09-19-2001, 10:46 PM
Special treatment is given to a fragment whose center lies on a boundary edge. In such acase we require that if two polygons lie on either side of a common edge (with two identical endpoints) on which a fragment center lies, then exactly one of the polygons results in the production of the fragment during rasterizaion.
I am not sure what you want to change about that. This case will happen in one scene about hmmm not very often. So it shouldn't be a prob.
09-20-2001, 07:13 AM
Actually, this is a very basic thing. This check guarentees that, if you have two polygons that share an edge, the edge will be filled in properly. Everybody's implementation does this (otherwise it wouldn't be a full OpenGL implementation. Not only that, polygons that share edges could show 1-pixel-wide gaps).
09-20-2001, 03:03 PM
OK, perhaps I misunderstood the spec, or perhaps not.
If a gap is left, it looks very ugly. If I can change how a polygon is rasterized, maybe I can solve this problem.
Anyways, this way, we can have more detailed control on how things are rendered - just like register combiners control texture output and such.
What do you think?
09-20-2001, 04:36 PM
What exactly is the problem that you are seeing? I haven't had any trouble with gaps between adjacent polygons as long as the polygons share vertices. If they just share part of an edge, I seriously doubt there is any way to deal with things in that instance.
09-20-2001, 08:37 PM
This is a problem for us to deal with, not you. You shouldn't have to worry about this.
09-21-2001, 01:51 PM
like I said, the 2 polygon have one identical edge. I'm not talking about sharing just *part* of an edge.
I'm tesselating a surface, so 1 triangle becomes 200 triangles and I see 10 or so "unfilled pixels" all over the surface.
Why in the world does this happen? I do have a geforce now, but this seems to occur on a lot of consumer cards.
09-21-2001, 11:12 PM
I guess you are not doing any push/pop matrix stuf between you tesselation and are not using textures or alpha values. And the setting of your clipping planes are correct. These are some of the points which come to my mind when thinking aobut unfilled pixel.
09-22-2001, 12:10 AM
"I'm tesselating a surface, so 1 triangle becomes 200 triangles and I see 10 or so "unfilled pixels" all over the surface.
Why in the world does this happen? I do have a geforce now, but this seems to occur on a lot of consumer cards."
It occurs because your code is doing something wrong. Somehow, it is not sending the exact same vertices for shared edges. All graphics cards guarentee that if you connect two polygons by fully identical vertices (bitwise equality is required) then there will not be any gaps. It certainly isn't the card.
At this point, I'd suggest asking in the advanced forum. Post some of your tesselation and rendering code.
09-23-2001, 10:42 AM
I think I have found the problem, but first let me say what I attempted to do:
My algorithm for breaking up the triangle into many may have cases where it might produce "non-binary identical" values, so I wrote another function to verify this and correct the mistakes. It did not find any mistakes! I tested on a sample set of data and it did correct the values, so it is bug free.
OK, the problem is that in some cases, the triangles produced were facing the wrong way. If the triangles are facing forward, there are no unfilled pixels. DONT confuse this with polygon culling since I have culling disabled.
So why are pixels getting unfilled when the polygons (GL_TRIANGLES) are not all facing forward (or backward)? I could give sample data if anyone wants.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.