PDA

View Full Version : clear color



nib
05-09-2007, 05:52 AM
Is there any kind of null case for when a shader can be called? For instance, where the fragments are just clear color and untouched. Hmm, I suppose the null case just maps to the nul shader. Just curious...

Zengar
05-09-2007, 07:12 AM
I don't understand the question, can you elaborate? You want to call a shader on fragments that are not rasterized?

nib
05-09-2007, 07:17 PM
Maybe, I'm confused.

For instance, a scene is drawn in one pass. But some tiny part of the background is the clear color. A program draws quad A and right next to it a quad B. But there is a stipple line between the two adjacent quads. The color of the stipple line is the clear color -- it was never drawn to but its color was set with glClear at the beginning. Its from the aliasing of the quads.

I figure that clear color gets rendered ( somehow internally ) and gave me the thought if I could intercept it with a fragment shader. Otherwise, I could just draw a giant quad in the background facing the camera directly and use a fragment shader. Then only the stipple would actually pass the depth test and call the fragment shader. But now I would have to test the entire scene which is what I wanted to avoid.

Zengar
05-10-2007, 05:59 AM
Hm, if the quads share the same edge (with same vertices coordinates) then you should see no gaps beetween the edges. This is the way GL is designed, adjacent primitives edges always touch. If you get gaps between adjacent priitives, then your driver is probably buggy or you messed with some settings (maybe you have line_stripple enabled?).

Relic
05-10-2007, 07:39 AM
Its from the aliasing of the quads. You mean anti-aliasing by enabled GL_POLYGON_SMOOTH?
That is to be expected if you render with depth test enabled.
The antialiased edges of the first quad mix with what was behind it when drawn (the clear color) and fill the depth values.
Another quad sharing an edge with that first quad will not be able to add more color to those edge pixels because the depth values block it from writing if the depth test is enabled and doesn't contain "equal". The default depth func is GL_LESS. => Stitch marks.

If that's it, I would just get rid of polygon smoothing. Full scene antialiasing is the more useful feature and doesn't require sorting and blending and won't show that problem.

If you just didn't render two quads with the exact same vertices on the shared edge, that would be a modeling problem on your side.

nib
05-10-2007, 08:33 AM
Ya, its probably the model. Still get the stipple in rare cases. Typically, on particular models, when the camera is over and looking along the model's edge. When I exported in Carrara Pro, I set the poly count to be reduced. Might be a case where the unit is suppose to be 50 but its 49.999. Probably rounding errors. Maybe, I should tessellate the model more along the edges. Well, when it comes to modeling programs: you get what you pay for. :)

The scene is models that are aligned together in a grid. Each model in the grid can be as big as you want and the grid can be as big as you want. The models happen to be composed of triangles. Its an analogous situation.

I try to sort the scene such that the depth will cut out as many fragments as possible. Hopefully, this helps with bump mapping with the glsl fragment program.

Zengar
05-11-2007, 03:08 AM
As said, make sure that primitives that share an edge have the same vertex position. So, if you have something like:


A
*---*
|\ |
| \ |
| \|
*---* B
Then coordinates of A and B have to be numerically equal on respect to both polygons, or else you _will_ get seams.