bugGNU Octave - Bugs: bug #44181, Tesselation lines visible in plot...

 
 

bug #44181: Tesselation lines visible in plot output of patches

Submitter:  Rik <rik5>
Submitted:  Tue 03 Feb 2015 09:04:19 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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:


        if (has_z)
          vv(2) = v(idx,2);


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).


Dan Sebald <sebald>
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.

Rik <rik5>
Group administrator
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)

Dan Sebald <sebald>
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:


xpdf -aaVector no patch4.pdf &


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/

GL2PS_POLYGON_OFFSET_FILL
    Emulates the GL_POLYGON_OFFSET_FILL functionality. The value of the offset is taken as the current value of the corresponding OpenGL offset (set with glPolygonOffset).
GL2PS_BLEND
    Emulates the GL_BLEND functionality. (Warning: this might change in future releases.)
GL2PS_POLYGON_BOUNDARY
    Not implemented yet.


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.

Dan Sebald <sebald>
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)


[Dlg Performance]
GraphicsAntialias=Disabled


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.

Rik <rik5>
Group administrator
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.

Dan Sebald <sebald>
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.

Pantxo Diribarne <pantxo>
Group Member
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.

Dan Sebald <sebald>
Sat 04 Apr 2015 11:13:57 PM UTC, comment #8: 


the rest of comment #7, I hope:


close all
x= [0 1 1 0];
y= [0 0 1 1];
patch (x,y,'r')
title ('foo^{bar}_{toto} \delta éàùçè', 'interpreter', 'tex')
print toto.svg
print toto.pdf


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

Pantxo Diribarne <pantxo>
Group Member
Sat 04 Apr 2015 11:12:11 PM UTC, comment #7: 

I had the following script run on Matlab R2014b:


close all
x= [0 1 1 0];
y= [0 0 1 1];
patch (x,y,'r')
title ('foo^{bar}_{toto} \delta éàùçè', 'interpreter', 'tex')
print toto.svg
print toto.pdf
-verbatim

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

(file #33540, file #33541)

Pantxo Diribarne <pantxo>
Group Member
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.

Rik <rik5>
Group administrator
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.

Dan Sebald <sebald>
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?

Rik <rik5>
Group administrator
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.


close all
x= [0 1 1 0];
y= [0 0 1 1];
patch (x,y,'r')
print toto.svg


The relevant part of the svg is:


<polygon fill="#ff0000" points="521.28,32.4 74.88,384.48 74.88,32.4"/>
<polygon fill="#ff0000" points="74.88,384.48 521.28,32.4 521.28,384.48"/>


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.


Pantxo Diribarne <pantxo>
Group Member
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?

Dan Sebald <sebald>
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:


          // NOTE: Push filled part of patch backwards to avoid Z-fighting with
          // tesselator outline.  A value of 1.0 seems to work fine.  Value
          // can't be too large or the patch will be pushed below the axes
          // planes at +2.5.


By the same logic, the code might be pushing the filled part backward past all patch outlines as well.

Dan Sebald <sebald>
Tue 03 Feb 2015 09:04:19 PM UTC, original submission:  

The following displays two patch objects


graphics_toolkit fltk
demo ("patch", 4)
print patch4.pdf


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


demo ("area", 1)
print area1.pdf



Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33583:  convexity.m added by sebald (784B - application/vnd.wolfram.mathematica.package)
file #33540:  toto.pdf added by pantxo (2KiB - application/pdf)
file #33541:  toto.svg added by pantxo (45KiB - image/svg+xml)
file #32987:  patch4_screen.png added by rik5 (10KiB - image/png)
file #32988:  patch4.pdf added by rik5 (3KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-07 sebald Attached File- Added convexity.m, #33583
    2015-04-06 rik5 StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2015-04-06 sebald Attached File- Added Screenshot-test_gl2ps.svg - Inkscape.png, #33559
        Attached File- Added Screenshot-test_gnuplotqt.svg - Inkscape.png, #33560
    2015-04-04 pantxo Attached File- Added toto.pdf, #33540
        Attached File- Added toto.svg, #33541
    2015-02-03 rik5 Attached File- Added patch4_screen.png, #32987
        Attached File- Added patch4.pdf, #32988

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code