Tue 07 Apr 2015 09:36:49 PM UTC, comment #16:
I just put the code here as a reference if ever someone wants to revisit the issue.
In any case, the convexity test isn't for 3D (there's only X and Y in the sample script). In the function opengl_renderer::draw_patch is already a variable "has_z" to discern whether a projection would be done:
in which case, if true, one wouldn't even check for convexity.
GLU does the tessellation, which I assume calls the OpenGL routine for convex polygons for each triangle. In the case of actual convex polygons, I don't see how triangulating the polygon can be more efficient, regardless of hardware--which nonetheless doesn't come into play for gl2ps, the original problem (i.e., tessellation artifacts).
|
Tue 07 Apr 2015 06:17:06 PM UTC, comment #15:
I think the nice thing about handing it off to OpenGL is that things can be HW-accelerated if the underlying chipset supports it. Checking the convexity of each of the polygons in a complex 3-D scene is not something that we want to do in Octave via software.
|
Tue 07 Apr 2015 05:47:05 PM UTC, comment #14:
I'm attaching a small script to illustrate checking for convexity. See the discussion here:
https://savannah.gnu.org/bugs/?44736
My thought was to add this test to patch.m (or _patch_.m, or _go_patch_.m, whichever is appropriate) and then call either the existing patch routine or one that is more simple using the OpenGL filled polygon routines as opposed to the GLU tessellation routines.
However, the
opengl_renderer::draw_patch (const patch::properties &props)
routine in gl-render.cc is rather long to replicate, so it would make more sense to pass in some property "isconvex". I don't know how to do that. Given the layout of the code, it seems easier to simply replicate the convexity test in C++ code of opengl_renderer::draw_patch.
(file #33583)
|
Mon 06 Apr 2015 04:45:44 AM UTC, comment #13:
Thinking about the characteristic of the line artifact, I got to wondering why it isn't a bright white pixel that is showing through. (On my printer, it actually is a rather bright single-pixel line half way through the hexadecagon.) I then began to suspect it is that smoothing is applied to rid sharp edges.
Viewing the patch4.pdf file in Acroread, go to the Edit:Preferences... menu and uncheck "Smooth Line Art" under the Rendering group. The lines disappear.
XPDF also has such an option de-selection, but it must be done at the command line:
The lines go away but the vector renderings look rather bad. When vector smoothing is on, XPDF does something worse than Acroread. Some of the lines come out darker than the blue polygon, not lighter. One would think if XPDF is smoothing the edges of the triangles it would combine the white background and blue to make something lighter between edges. The darker lines are inside of the black outline of the octagon. Strange.
Is there a way for PostScript code to force vector smoothing off? There are all sorts of things like image interpolation, image masking, stencil masking, etc.
Are these relevant?
http://www.geuz.org/gl2ps/
https://www.opengl.org/sdk/docs/man3/xhtml/glPolygonOffset.xml
Name
glPolygonOffset — set the scale and units used to calculate depth values
If not, I'll go with closing this bug report as Will Not Fix. The source of the problem ultimately goes back to the triangulation of the polygon.
|
Mon 06 Apr 2015 04:35:50 AM UTC, comment #12:
I've definitely confirmed it is the renderer. If I use 'gv' there is an option to enable/disable antialiasing. Without anti-aliasing the file shows up just fine.
Similarly, If I add the following to okularpartrc (~/.kde/share/config)
to disable anti-aliasing then Okular also displays the file polygon correctly (although without the anti-aliasing the lines are jagged).
So, I'm going to mark this as invalid. It doesn't seem to be the file generated by Octave that is the problem.
|
Mon 06 Apr 2015 01:23:13 AM UTC, comment #11:
Sorry, it IS aliasing, not some bogus line. I installed Inskape, generated the patch demo figure as an SVG and loaded it into Inskape. After ungrouping all objects to their minimum I could slide one of the slices around and create all kinds of visual effects. (See attached Screenshot-test_gl2ps.svg - Inkscape.png.)
SVG is aliasing in Inkscape. GV on the postscript file does a good job. But ps2pdf creates aliasing. I printed the PS file directly to my HP Laserjet 2200 and see only one aliasing line, but it's very visible.
OpenGL on the terminal screen looks good, but we aren't sure that is drawn with triangles. Using gnuplot graphics toolkit, I sent the patch demo to gnuplot's Qt terminal and saved the file as an SVG. Loading that into Inkscape and ungrouping only got so far as the blue hexadecagon, i.e., apparently no triangles. (See attached Screenshot-test_gnuplotqt.svg - Inkscape-1.png.)
Could be gl2ps, just a guess.
|
Sun 05 Apr 2015 08:53:52 PM UTC, comment #10:
@Dan: please simply read (as it is text based) gl2ps svg output, perhaps you'll find your bogus line. Also please try to make a simple svg image (e.g. using Inkscape) with tangent polygons and report back after a real investigation. Sorry for the tone, I don't like to argue on pure suppositions.
|
Sun 05 Apr 2015 05:53:14 PM UTC, comment #9:
That doesn't sound correct to me.
I understand what the aliasing issue is, i.e., if there are two fill objects sharing the same border having the same coordinates (which is what the OpenGL fill is doing in this case, building the fill from individual triangles...it could do better than this, of course). The render could create some pixel wide "seam", i.e., the background color comes through maybe every few pixels if the line happens to be on a slant or something.
However, I don't think that is the case here because we are seeing some rather wide gray tessellation lines. More than that, some of these grey tessellation lines are dashed lines, of all things.
Furthermore, I just reported another bug:
https://savannah.gnu.org/bugs/?44736
in which some strange fills/outlines are plotted on top of the axis lines in grey.
SVG is created via gl2ps, as is PS and PDF. I'm beginning to suspect that gl2ps is putting some strange artifact into the plots...perhaps associated with fills, and possibly after a fill/outlined-fill is used gl2ps goes into some strange state where it continues to place (what is a bogus) outline around anything fill-like. Perhaps Octave is missing some initialization or setup of gl2ps.
|
Sat 04 Apr 2015 11:13:57 PM UTC, comment #8:
the rest of comment #7, I hope:
I attached the svg and pdf outputs. As far as I can see the tessellation line
is visible in both formats whether I use Okular or Inkscape to render them.
I also asked on Inkscape mailing list the reason why we saw the separation
between to tangent triangles [1]: I was explained that it was due to
inkscape's anti-aliasing and that it had been improved in the last release.
FWIW the Inkscape's eps/pdf output of two perfectly neighbor triangles is not
rendered better than Octave's in Okular and Evince.
My impression is that there is nothing simple to do about it on our side: it
is the viewers' job to handle those visual artifacts.
Improving this would mean regrouping triangles into their original polygon
(patch) representation: sounds like rewriting a renderer not based on OpenGL
would be easier ...
[1] http://inkscape.13.x6.nabble.com/Tesselation-lines-in-svg-td4973255.html
|
Sat 04 Apr 2015 11:12:11 PM UTC, comment #7:
I had the following script run on Matlab R2014b:
|
Sat 04 Apr 2015 08:19:51 PM UTC, comment #6:
@Dan: Please open up a different bug for "edges of overlapping patch objects". That is due to an entirely different issue than the tesselation lines.
|
Sat 04 Apr 2015 07:47:29 PM UTC, comment #5:
Remember, there is still a bug here related to the depth of the filled surfaces and outline. Compare "demo ("patch", 4);" for both gnuplot toolkit and one of the OpenGL toolkits. I'm thinking that outline for the green octagon should be lower in depth.
I will look into the tessellation issue with OpenGL, now that I know much more about Mesa. Could be another upstream bug. Mesa has a low level test suite, and if there isn't one for this type of fill, I will consider writing one.
|
Sun 29 Mar 2015 06:04:01 AM UTC, comment #4:
The problem is that the output is worthless for electronic publication as currently rendered. Matlab manages to use OpenGL for onscreen rendering. Do they have an equally bad problem with their output?
|
Sat 28 Mar 2015 12:05:58 PM UTC, comment #3:
If you generate an svg instead of a pdf you will be able to edit the coordinates of the triangle vertices: as expected the vertices of common edges have the exact same coordinates.
The relevant part of the svg is:
It looks like the tessellation line that we see is a "visual hint", drawn by the viewer, that indicates that there are 2 polygons.
So I am under the impression that unless there is a flag, defined in pdf/ps/svg specifications, that instructs the viewer/printer that it should not draw this "visual hint" I don't think octave/gl2ps can do anything about this: opengl/gl2ps will always tessellate polygons into triangles.
|
Fri 20 Feb 2015 05:00:29 AM UTC, comment #2:
Oh yeah, I suppose the patch routine needs to work for non-convex filled patches as well, not just simple convex polygons. And the graphics library doesn't handle that well, I assume. E.g., perhaps creates a convex fill from a non-convex border described by the vertices?
|
Fri 20 Feb 2015 04:50:06 AM UTC, comment #1:
I just tested this here and found similar behavior. I printed out the data and the vertices look in order, the faces are in order as well (faces indexes the vertices to describe the polygon). I looked at the code, and do see a large hunk of code about tesselation in gl-render.cc. Whether that is called in this case, I'm not sure. Doesn't the graphices library accept all the vertices at once and draw without tesselation?
I'm wondering about the border of the green octagon being drawn on top of the blue hexadecagon. That is similar for both FLTK and Qt, but for gnuplot terminal the border of the green octagon is also behind the blue hexadecagon. One of them is wrong. I don't see any inputs to patch in the demo that would control the depth of the border versus the depth of the face. Another bug report? It may be in the same file and part of the same code. E.g., in gl-render.cc is this note:
By the same logic, the code might be pushing the filled part backward past all patch outlines as well.
|
Tue 03 Feb 2015 09:04:19 PM UTC, original submission:
The following displays two patch objects
The on screen result is good (in the attached file patch4_screen.png). The generated pdf shows faint lines where OpenGL broke the object into triangles for display. Can this be improved? Is there an option to throw to gl2ps to make it better. The situation is even worse for
|