FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 580 : Stroked polygons losing stroke pixels due to z-buffer issues in P3D
Last modified: 2007-08-28 19:20
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
ASSIGNED
Resolution:
-
Pr
i
ority:
P5
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
ewjordan
Assigned To:
fry
Attachment
Type
Created
Size
Actions
Description
: Opened: 2007-06-11 14:15
Quite generally, stroked triangles are getting stroke pixels blocked
because of the z-buffer. In theory the z-buffer of the stroke should equal
that of the fill if the two overlap, and since the stroke is drawn second
it should "win," but numerically the two do not turn out to be equal for
various reasons. There is probably a hacked-together way to fix this
(subtract some small amount to the z-buffer for strokes) and a true one (go
through the line/triangle codes in detail and figure out a way to alter the
algorithms so that the edges match up), I'm not sure which one would be better.
OpenGL handles this correctly, only dropping pixels from the stroke if they
are on the back edges of the triangle; P3D drops many even on the front ones.
Additional Comment
#1 From fry 2007-06-14 13:48
right, so we've done this in the past in various ways. if you offset too
much, then stroke appears on top of everything (see a whole slew of bugs on
the board from the days of 0085+). so getting this right will be tricky...
come to think of it, i wonder if opengl implementations have anything
clever they use for this (they may not since the accuracy thing isn't so
much of an issue) a peek at the mesa source might provide some clues.
Additional Comment
#2 From ewjordan 2007-08-03 21:22
I looked into this a little more, and it actually doesn't seem like OpenGL
handles it altogether perfectly either, at least on my machine, though it
definitely does a bit better than P3D. It may just be true that relying on
stroked 3d polygons isn't such a great idea unless you're willing to offset
the stroke and draw it separately yourself. I looked a bit through the
Mesa source, but wasn't able to figure out much of anything - it would take
a while for me to familiarize myself with the project, and at the moment I
can't pick out where the rasterization happens.
I suspect this is again coming down to the same old subtle issues about how
to decide pixel coverage and all that stuff, so I guess it's probably not
worth wasting too much energy on - if I want stroked objects, I'd generally
generate the strokes in 3d anyways so I can set the weight and have the
joins how I'd like them. If I think of anything, I'll give it a try, though.
Additional Comment
#3 From fry 2007-08-28 19:20
yeah, probably fine to just note this for now and leave it as a lower priority.
This bug is now being tracked
here
.