Add a New Comment (Rich Markup)
( Jump to the original submission )
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
The code is in gl-render.cc in draw_patch.
patch_tesselator tess (this, fc_mode, fl_mode, 1.0); and then tess.begin_polygon (true); tess.begin_contour ();
The patch_tesselator class is defined in gl-render.cc at the top of the file. The begin_polygon() routine is
void begin_polygon (bool filled = true) { gluTessProperty (glu_tess, GLU_TESS_BOUNDARY_ONLY, (filled ? GL_FALSE : GL_TRUE)); fill = filled; gluTessBeginPolygon (glu_tess, this); }
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.
Another pertinent OpenGL command: https://www.opengl.org/sdk/docs/man3/xhtml/glPolygonMode.xml Still, nothing about how the fill is done.
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
opengl_renderer::draw (go);
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.
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.
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.
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
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)
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?
For this demo using the command "patch":
graphics_toolkit qt demo ("patch", 4)
the outline of the axis appears fine when displayed in OpenGL. However, the following gl2ps print:
print test.ps
(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:
print test.pdf
(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
1 1 1 RG 1 1 1 rg 5392.8 5806 m 5392.8 2285.2 l f 5392.8 5806 m 928.801 5806 l f
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".
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 3 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11