bugGNU Octave - Bugs: bug #44736, OpenGL / gl2ps printing alters or...

 
 

bug #44736: OpenGL / gl2ps printing alters or drops axis outline

Submitted by:  Dan Sebald <sebald>
Submitted on:  Sun 05 Apr 2015 05:35:01 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Need Info Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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

Dan Sebald <sebald>
Mon 06 Apr 2015 05:59:45 PM UTC, comment #8: 

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.

Rik <rik5>
Project Administrator
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.

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

           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.

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

Rik <rik5>
Project Administrator
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.

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

Rik <rik5>
Project Administrator
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)

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

Rik <rik5>
Project Administrator
Sun 05 Apr 2015 05:35:01 PM UTC, original submission:  

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

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33561:  patch4.ps added by sebald (99KiB - application/postscript)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-06 rik5 Open/ClosedOpen => Closed
    2015-04-06 sebald Attached File- => Added patch4.ps, #33561
    2015-04-06 rik5 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.7