Subject:
|
Re: Type 5 lines, BFC relevance, and OpenGL
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 1 Apr 2005 06:26:54 GMT
|
Viewed:
|
1979 times
|
| |
|
|
Mark Tarrabain wrote:
>
> Interesting... so this article is suggesting that type5 lines not be
> used at all, which may be possible for a model that is certain to be BFC
> compliant.
I think, that in this particular application it is better to deal with line type
5 syntax. Otherwise renderer has to calculate angle between adjanced polygons
and select some threshold to decide whether this line is "conditional" or not.
Angles may be calculated at load time, but all smooth surfaces must be smooth
enough to do not overlap with "unconditional" edges.
Mark Tarrabain wrote:
> Wheras the mechanism I was suggesting would work for any model, BFC
> compliant or not. The fundamental principal appears to be
> fundamentally the same (of inverting the stencil buffer), but I think
> the way I've described it would be easier to implement.
Yes. I tested it and it is very likely to work - I do not have too deep
understanding to confirm absolute correctness, but it never failed in my tests.
Actually, I'm very impressed by this alogirithm.
Don Heyse wrote:
> >
> > The one thing that worries me about this is whether the opposite
> > vertex order for the two lines will result in slightly different
> > pixels. I know bresenham produces different pixels for AB and BA.
> > If this happens you'll get some stray 1 pixels in the stencil buffer
> > where the lines were supposed to cancel and they didn't quite match
> > exactly. I had a problem like this on the nvidia TNT where the
> > opengl pipeline produced slightly different results in the stencil
> > buffer, just because I enabled GL_COLOR_LOGIC_OP for one pass.
> > apparently they don't guarantee the same pixels for different paths
> > through the opengl pipeline.
> >
> > You might want to draw both polygons C and D, just in case the vertex
> > orders produces different pixels. This way you're sure to match (and
> > erase) ALL the stenciled pixels.
Mark Tarrabain wrote:
>
> Gah... I hadn't even thought of that. I guess the way around it would
> be to draw the edge _4_ times rather than just twice. Cull backfacing
> polygons, then draw C and D. Turn on backfacing polys, cull fore-facing
> polys, then redraw C and D with the vertices listed in opposite winding,
> all the while using the stencil buffer invert. And then when actually
> doing the real drawing, again draw both C and D. Woah... that
> completely doubles the amount of drawing that has to occur, but should
> be guaranteed to handle the case correctly where different pixels get
> produced because of different vertex orders. Again, it's still possible
> to put into a display list, which is what this was all about.
Why not draw only polygons with the same vertex order? Sequence is exactly as
you wrote, but do not double polygons. Following implies, that p1 and p2 are
points for conditional line, p3 and p4 are "extra" points and polygons are
painted with edge flags as described:
1. glEnable(GL_CULL_FACE);
2. glCullFace(GL_FRONT);
3. // paint polygon p1-p2-p3
4. glCullFace(GL_BACK);
5. // paint polygon p1-p2-p4
6. glDisable(GL_CULL_FACE);
7. // paint polygon p1-p2-p3
or even better change steps 6-7 to:
6-7. // paint line p1-p2
This sequence may be optimized further - depending of the implementation, one
would no needed execute #1 for each conditional line, lines may be grouped to
run #2 and #4 only once for the sequence etc.
WBR,
Alexander Horoshilov
|
|
Message is in Reply To:
 | | Re: Type 5 lines, BFC relevance, and OpenGL
|
| (...) Interesting... so this article is suggesting that type5 lines not be used at all, which may be possible for a model that is certain to be BFC compliant. Wheras the mechanism I was suggesting would work for any model, BFC compliant or not. The (...) (19 years ago, 31-Mar-05, to lugnet.cad.dev)
|
9 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
