Subject:
|
Type 5 lines, BFC relevance, and OpenGL
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Mon, 28 Mar 2005 22:10:50 GMT
|
Viewed:
|
2065 times
|
| |
|
|
I wanted to bounce something that has been percolating in my brain for a
few days off somebody that might be able to offer me some feedback on
it. I don't know if I'm the first person to think of this (I'm
probably not), but as I haven't seen anything like this, the possibility
remains (however slight) that this might be an original idea, so I hope
you'll hear me out here.
Consider that a type 5 line is (probably) going to be a line that
overlaps the boundary of two polygons elsewhere in a model. I assume
that for any particular type 5 line in a model, it should be possible to
discover which two polygons in the model it is adjacent to after having
read it into memory and processed it.
Now my understanding is that one of the big problems with type 5 lines
was that unless you are going to do runtime visibility checking each and
every time you _might_ have to display them (which negates any
possibility of putting it into a display list), the only really sane way
to handle them is if the model happens to be BFC compliant since systems
like OpenGL can fairly easily handle things like sillhouetting as long
as the model's polygons have a consistent orientation.
However, I was thinking that it may still be possible to do the same
thing, even _without_ BFC compliance... at the expense of passing two
extra polygons per optional line. Further, if the OpenGL implementation
supports vertex caching, this should be even speedier. Presumably the
overhead saved by putting the whole model into a display list should
more than compensate for the processing the extra triangles anyways.
After this paragraph, whenever I refer to a type 5 line, I will be
referring to some shared polygon boundary in the model where no explicit
line drawing was given and where the angle between the two planes of the
polygons adjacent differ by more than some very small threshold. This
may or may not actually correspond to real type 5 lines in a model
file... I do not know (although I suspect that they would).
So consider that a type 5 line represents a border between two polygons
in the model.... the catch here is that you only want to display that
line if the two polygons are facing different directions, but how can
you, or OpenGL for that matter, tell if they are facing different
directions if they might have an inconsistent orientation? The answer
is simple... make up two polygons that _DO_ have a consistent orientation!
Okay, I may have lost you... I can tell. bear with me here while I try
to explain.
At the moment all we are trying to do is work with a single type 5 line
that may, or may not, get drawn. This type 5 line shall be considered
to be adjacent to, let's say, polygons A and B in the model, which
happen to share an edge (the type 5 line).
What we should do now is construct two polygons, C and D, which should
both be triangles (for simplicity), as follows:
The first two vertices of C should be the endpoints of the type 5 line
itself, and the final vertex of C should be any other vertex from A not
on the line. The first two vertices of D should be the type 5 line
listed in reverse order, and the final vertex of D should be any other
vertex from B not on the line.
Now we have two polygons, C and D, with a consistent orientation. At
this point, it does not matter if they are front facing, back facing, or
facing in opposite directions. OpenGL can still correctly do things for
us, regardless. Note that all of this can be computed in well in
advance of actually rendering, and never changes at any time unless the
part in question is actually the one being edited.
Now... on to the rendering details.
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 <=. (I have heard some older OpenGL
implementations didn't support stencil buffers simultaneously depth
buffers, I do not know how serious an issue that is today. Hopefully
it's a non-issue these days). 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.
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. 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). 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.
Obviously, if many type 5 lines are processed together, you can optimize
this slightly by not disabling and reenabling the stencil test each time.
And there you have it... Type 5 lines, insertable anywhere into an
OpenGL display list, regardless of the model orientation.
|
|
Message has 1 Reply:
 | | 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
|
|
|
|
