Mon 06 Apr 2015 06:46:57 PM UTC, comment #9:
Oh, OK. I didn't know there was an extension to OpenGL.
Well, yes the tessellation version of the polygon routine is for concave (and convex) fills, as the documentation says:
https://www.opengl.org/sdk/docs/man2/xhtml/gluTessBeginPolygon.xml
Octave can avoid using this tessellation and instead use the convex fill in the case that the patch is convex--especially simple in the case of known convex shapes such as the background rectangle of the plot. (glRect would work for that as well.)
For 2D polygons it isn't difficult determining convexity. Start with one vertex and group three at a time working around the polygon. Compute the angle between the two lines assuming the center vertex is the intersection point. It's probably some simple 2x2 matrix inversion formula (hyperplanes or something like that). If all the angle signs are positive or zero, or all negative or zero, then the polygon is convex and Octave can fall back on the convex polynomial draw/fill of the base OpenGL library:
https://www.opengl.org/sdk/docs/man2/xhtml/glBegin.xml
|
Mon 06 Apr 2015 05:59:45 PM UTC, comment #8:
The code is in gl-render.cc in draw_patch.
The patch_tesselator class is defined in gl-render.cc at the top of the file. The begin_polygon() routine is
Octave gives over the vertices to OpenGL which then breaks the polygon into triangles and calls the vertex() callback (line 459) for every vertex to set color and lighting properties.
|
Mon 06 Apr 2015 05:47:31 PM UTC, comment #7:
Another pertinent OpenGL command:
https://www.opengl.org/sdk/docs/man3/xhtml/glPolygonMode.xml
Still, nothing about how the fill is done.
|
Mon 06 Apr 2015 05:33:21 PM UTC, comment #6:
OpenGL, or Mesa? OpenGL doesn't call out how the fill is done, just that given the vertices, the polygon is convex
https://www.opengl.org/sdk/docs/man2/xhtml/glBegin.xml
Searching via grep, I see GL_POLYGON in the Octave gl-render code, there are a couple uses of GL_QUADS, but I see no GL_TRIANGLE. So Octave isn't the source of triangulation, which was sort of confirmed by gnuplot not having triangulated fills.
The way this is laid out in gl2ps-renderer.cc, it seems that gl2psBeginPage() puts the OpenGL interface into some mode which redirects commands to the gl2ps library. After gl2psBeginPage() is
which I'm assuming calls the code in gl-renderer.cc.
So, it doesn't seem like gl2ps interacts with Mesa or its drivers. I'm more inclined to think it is gl2ps doing the triangulation at this point. If it were a Mesa issue, I'd ask their discussion list what could be done. But gl2ps isn't something I want to mess with right now.
|
Mon 06 Apr 2015 11:06:14 AM UTC, comment #5:
The root cause is OpenGL itself which breaks a scene into multiple small polygons, almost invariably triangles. gl2ps just captures that output in Postscript form. It would be nice, I suppose, if gl2ps could coalesce triangles back into full polygons, but thats a large project and I understand why they haven't taken that step.
|
Mon 06 Apr 2015 06:32:49 AM UTC, comment #4:
It may be a viewer issue, but I think only because the layout of objects is such that it brings out the intricate rendering details of the viewer.
I import patch4.svg into Inkscape and then decompose the plot into atomic elements. The white background is drawn as two triangles rather than a rectangle. Not a surprise, I suppose, given the octagon and hexadecagon are triangulated. And there are, in fact, some other elements coinciding with the right and top border--some sort of zero thickness fill that only shows up as dashed outlines in Inkscape--something that I can grab and move around. There are two such phantom fills for both the top and right axis borders. The left and bottom borders have no such phantom fill. I believe that is the source of the problem.
I don't think there is anything that Octave can do. gl2ps needs to lay things out in a more render-friendly fashion.
|
Mon 06 Apr 2015 05:35:21 AM UTC, comment #3:
patch4.ps works if I disable antialiasing in gv. It also works in Okular with antialising disabled. So I don't think this is an Octave issue, but rather a ps/pdf viewer issue
|
Mon 06 Apr 2015 05:13:30 AM UTC, comment #2:
Attached is the PS file resulting from "print patch4.ps".
Don't have okular, and no easy RPM file. This is related to the vector smoothing, I think.
In GV, with Antialias on, both the top and right axis lines are gray (i.e., smoothed, probably with a white background filled rectangle?). Turning off Antialiasing, the top axis border becomes visible like the left and bottom, but the right axis border completely disappears.
Using ps2pdf on the file, in Acroread there are no black border lines for top and right either with Edit:Rendering:Smooth-line-art on or off. But with XPDF, both black border lines right and top appear when "-aaVector yes" is used and neither border lines right and top visible when "-aaVector no" is used--that may seem like I wrote that backward, but it is correct.
There is some kind of interaction happening with those white fills I listed below. Whether those are supposed to be for a white background, I don't know.
(file #33561)
|
Mon 06 Apr 2015 04:40:21 AM UTC, comment #1:
Can you try using another viewer besides gv? I find that gv with antialias "on" shows the axis correctly, but with it off the axis is dropped. This doesn't happen with okular so I think it is weirdness with gv.
Also, can you attach test.ps so that I can view it?
|
Sun 05 Apr 2015 05:35:01 PM UTC, original submission:
For this demo using the command "patch":
the outline of the axis appears fine when displayed in OpenGL. However, the following gl2ps print:
(viewable in "gv test.ps") produces an image in which the right and top outlines of the axes is very light grey, not black.
Converting that PostScript file to PDF via:
(viewable in "acroread test.pdf" or "xpdf test.pdf") shows no right or top outline at all, not even grey.
In the PostScript file are the following elements
which, if removed, correct the black outline of the axes.
Where did these come from? Are they supposed to be a white fill of the axis line (which makes no sense)? Both of these elements have zero width. Could it be that there is no fill, but the tessellation line issues described here:
https://savannah.gnu.org/bugs/?44181
is still drawing a grey line around what is a zero width fill?
Perhaps the ps2pdf routine is programmed to toss out elements of zero width and so doesn't draw the the grey tessellation lines, as does "gv test.ps".
|