Subject:
|
Re: Type 5 lines, BFC relevance, and OpenGL
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 31 Mar 2005 17:08:04 GMT
|
Viewed:
|
2027 times
|
| |
|
|
Don Heyse wrote:
> 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.
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 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.
> > 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.
I hadn't thought of the idea of using the depth buffer mask to disable
depth buffer writing... that would work. Disable the depth buffer mask
at the same time that you disable the color channels, and then reenable
it when you reenable the color channels. This is a good idea.
> > > 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.
Also, something else I hadn't thought of. This is exactly why I wanted
to bounce the idea off someone here... because there's only so far that
a person can go by themselves.
> > > 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.
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.
> > > 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
Thank you so much for your comments and suggestions... I appreciate it
immensely.
>> Mark
|
|
Message has 1 Reply:
 | | Re: Type 5 lines, BFC relevance, and OpenGL
|
| (...) 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. (...) (20 years ago, 1-Apr-05, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Type 5 lines, BFC relevance, and OpenGL
|
| (...) You know, this got me thinking last night. I knew it sounded vaguely familiar, so I searched lugnet for "stencil buffer" and found this. (URL) I was so close, but somehow got distracted before I could work it out. Damn that attention deficit (...) (20 years ago, 30-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
|
|
|
|
