In our application we need to rasterize triangles in such a way that the boundary of the non-rasterized triangle is as close as possible to the boundary of the rasterized triangle.
In other words, when a triangle intersects with a pixel (independent of how small this intersection is) the fragment should be filled. (We need non-anti aliased, flat shading.)
This is different from the OpenGL specification that states that the center of a pixel must be inside the polygon in order to become a fragment. The closest I can come to what I need is to render the triangles both with FILL, LINE, and POINT polygon mode, but still this is not exactly what I need.
My question is how to obtain a rasterization where all pixel that have a non-empty intersection with the triangle become fragments? And, if possible at all, how this can be done efficiently?
Any help or pointers are welcome,
Edwin
The first thing I’d try would be drawing the triangle four times, jittered half a screen pixel diagonal (once for each diagonal direction).
The CPU or a geometry shader would be used to produce the four triangles from the original.
There’s a section about pixel exact rendering somewhere (is it in the Red Book?), which might have some useful theoretical information.
[Just an observation - you can have non-antialiased flat shading without the inclusive rasterization policy you describe.]
Thanks for you answer.
4x drawing the triangle does not solve the problem in general. Consider for example a triangle that after projection fits easily in a pixel. Displacing this triangle additional by a half pixel in four direction still does not guarantee that it covers the center of the pixel. (I know, the particular example I give would be solved by POINT rendering of the triangle in addition to fill.)
[The flat shading / no-anti aliasing remark was made only that I don’t need anything advanced.]
If it would be possible to render the triangle with in LINE polygon mode such that the lines are rendered with the point sample method that I need, then that would solve my probem as well.
What about using :
glEnable(GL_POLYGON_SMOOTH);
glDisable(GL_BLEND);
// draw stuff
Zbuffer, thanks for you answer.
The problem I actually need to solve is finding the distance to a set of objects in a scene where the distance is the minimal distance to the visible (non-hidden) parts of the objects.
The distinct objects have distinct colors, so, colors actually are object_IDs. That is why flat shading without anti aliasing need to be used. Our application is a scientific application, the error in the distance measurement needs to be minimal, hence my wish for a different point sampling algorithm for the filled polygon rendering. We don’t care about how appealing the renderings look (we don’t even see them).
The point is, the problem that we want to solve is a classic 3D probem, and GPUs are developed to solve this problem efficiently … almost. It is this tiny detail (the criterion to decide that a fragment is filled) that seems the fly in the ointment (that is, we now need to render with at least the double horizontal and vertical resolution to get the desired distance error).
Yeah whatever, did you try my suggestion or not ?
Because it should do exactly what you need.
Not yet, I am going to. I overread the gl[b]Disable/b and decided that blending is not what I want.
Thanks, looks promising.
Just tried and unfortunately whereas GL_LINE_SMOOTH did create smoothed lines, GL_POLYGON_SMOOTH did exactly nothing, even with nicest hint, so either I did something wrong, or that feature may not be supported sometimes …
nvidia GTX 275, driver 258.96 on windows vista64sp2
Meanwhile I was busy trying to get this working as well, but then from OSG. But, with the same result as you have:
state->setMode( GL_POLYGON_SMOOTH, osg::StateAttribute::ON | osg::StateAttribute::PROTECTED);
Did nothing. Neither on my triangle node, nor on its parent.
I’m trying to do something simular to Rijpkema. Searching around I’ve seen a lot of comments around saying that some new cards are not supporting GL_POLYGON_SMOOTH - too bad, cause it would work great.
An alternate method I found is to draw the triangles normally (glPolygonMode - GL_FILL), then draw them again with glPolygonMode GL_LINE.