Subject:
|
Re: Type 5 lines, BFC relevance, and OpenGL
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 30 Mar 2005 22:19:30 GMT
|
Viewed:
|
1883 times
|
| |
|
|
In lugnet.cad.dev, Don Heyse wrote:
> Hmmm, draw the edge twice and flip the stencil bit eh? It sounds
> like it could work. I'll have to read up on edge flags. I haven't
> used them for anything yet.
>
> By the way, you should be able to get all the info you need from
> the type 5 line itself, without examining the adjacent polygons
> A and B. Remember the type 5 line has 4 points: Two on the line
> itself, and two from the adjacent polys (or somewhere equivalent
> enough for this algorithm).
>
> Let's see it in some code.
You know, this got me thinking last night. I knew it sounded
vaguely familiar, so I searched lugnet for "stencil buffer" and
found this.
http://news.lugnet.com/cad/dev/?n=7127
Arrgh! I was so close, but somehow got distracted before I could
work it out. Damn that attention deficit disorder! Now what was I
saying? Oh yeah, I resolved to actually try it this time and started
coding it up last night in ldglite. I've got some notes on the
algorithm.
> In lugnet.cad.dev, Mark Tarrabain wrote:
> > First of all, tell OpenGL to draw polygons as outlines only. Also,
> > enable the stencil test. Make sure the depth testing is either
> > disabled, or else set to <=.
Actually I think you can leave the depth test alone and simply disable
depth writes with glDepthMask(GL_FALSE) just like the colorMask below.
I use a slightly different depth fn when I'm antialiasing, so I'd
rather not touch it.
> > Next, call glColorMask() with GL_FALSE for all channels so that no
> > actual drawing occurs for the moment. Now set the stencil function
> > to always pass, and set the stencil operation so that it is simply
> > set to invert whatever value is already there.
If you disabled depth writes with glDepthMask() I think you can use
use GL_KEEP for the zfail fn.
glStencilFunc(GL_INVERT, GL_KEEP, GL_INVERT);
This might save a few stencil pixels where the lines are already
obscured by something closer in the Z-buffer.
> > Next, tell OpenGL to cull all backfacing polygons (patience, you'll see
> > how it works in a moment). Then draw (in GL_LINE mode) both polygons C
> > and D with the edge flag only set to true for their first edge, and all
> > other edges have the edge flag as false. Because the color masks are
> > set to false, nothing will get actually drawn on screen, but the stencil
> > buffer will still be adjusted. Recognize at this point that if both
> > polygons were actually back-facing, then the stencil buffer remained
> > unaltered, and will be 0. If both polygons were front-facing, the
> > stencil buffer will get inverted for the first polygon, then inverted
> > again for the second, and so will still be 0.
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.
> > Now call glColorMask() with GL_TRUE for all channels to re-enable
> > drawing, set the stencil function to only pass when stencil != 0,
> > and set the stencil op to always clear the stencil buffer. Now tell
> > OpenGL to draw both front _and_ back facing polygons, and then draw
> > only the outline of polygon C, exactly as before (with edge flag set
> > to true only for the first edge, false for the others).
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.
> > The stencil func will keep the line from being
> > drawn if the stencil value is at 0. Finally, you disable the stencil
> > test, and carry on with the rest of your model.
Have fun,
Don
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Type 5 lines, BFC relevance, and OpenGL
|
| Hmmm, draw the edge twice and flip the stencil bit eh? It sounds like it could work. I'll have to read up on edge flags. I haven't used them for anything yet. By the way, you should be able to get all the info you need from the type 5 line itself, (...) (20 years ago, 29-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
