bugGNU Octave - Bugs: bug #44735, OpenGL patch outline has incorrect...

 
 

bug #44735: OpenGL patch outline has incorrect Z depth with respect to other patch fill colors

Submitter:  Dan Sebald <sebald>
Submitted:  Sun 05 Apr 2015 05:10:57 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  3 - Low Item Group:  Matlab Compatibility
Status:  Fixed 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

Sat 21 Oct 2017 09:38:42 PM UTC, comment #9: 

Yeah, I wish we had a better way of resolving the tesselation lines short of asking the user to configure their PDF browsers a certain way.

Closing this report.

Rik <rik5>
Group administrator
Sat 21 Oct 2017 09:25:39 PM UTC, comment #8: 

I have just re-tried several of these examples here.  It appears that on my system, the "broken" floating octagon outline is no more.  Both the green octagon and its black outline are hidden by the blue hexadecagon.  (I now have a fairly up-to-date distro in Linux Mint 18.2 Sonya.)

From what I'm understanding, Matlab is producing a PNG (foo.png) that has the "broken" floating outline.  I take it that this issue is at the hands of the underlying OpenGL library and not an application bug.

In addition, ML produces a PDF file that does not have the "broken" floating outline.  Octave also does not produce such a line in PDF.  However, Octave does create some tesselation lines interior and also some odd grey lines outlining the whole plot area, including background.  The latter is probably the same issue as the former in some way.

As I see it, there is nothing more that can be done, and the tesselation issue is known and documented elsewhere.  I'm all-right with closing this bug report.

Dan Sebald <sebald>
Sat 21 Oct 2017 08:51:57 PM UTC, comment #7: 

Can we close this report?  It appears we are Matlab compatible.

When using multiple patch commands, as in the example code from comment #4, there is no visible outline from the green patch because it is overlapped by the blue patch.

When using the example code from comment #1, the outline of each polygon is visible because a single OpenGL patch object is being used.  That also seems Matlab compatible.

Rik <rik5>
Group administrator
Sun 15 Oct 2017 09:23:37 PM UTC, comment #6: 

The sample code from comment #4 now works like in Matlab, i.e there is no overlapping line, but the original issue remains.

The opengl renderer doesn't use depth sorting anymore when drawing pure 2D plots. For patches drawn one after the other (see comment #4) this works well since each outline is drawn right after its corresponding fill content. In the original example there are 2 faces in one patch so the fill content is drawn first (with 2 colors) and the outlines after.

Pantxo Diribarne <pantxo>
Group Member
Fri 19 Jun 2015 07:01:00 PM UTC, comment #5: 

The reason for the difference is probably that gl2ps can natively produce pdf output, but png output is generated by creating Postscript and then converting that Postscript to png.

I just tried the sample code from comment #4 and at least Octave is consistent.  The on-screen representation shows the overlapping line, the pdf printout shows the overlapping line, and the png shows the overlapping line.

Rik <rik5>
Group administrator
Fri 19 Jun 2015 05:53:04 PM UTC, comment #4: 

one additional observation (from bug #45357):

If, in ML, one does two extra patches


patch ('Faces',1:8, 'Vertices',vert(1:8,:),'FaceColor',[0, 1, 0]);
patch ('Faces',1:16, 'Vertices',vert(9:24,:),'FaceColor',[0, 0, 1]);
print -dpng foo.png
print -dpdf foo.pdf


the edge becomes hidden. And interestingly, it is also hidden in the pdf output but not in the png (see attached).

file #34268)

Muhali <muhali>
Tue 07 Apr 2015 04:07:12 PM UTC, comment #3: 

I'm lowering the priority of this bug since we are at least as good as the competition.  Maybe we could do better, although from my experience with OpenGL and the code in gl-render.cc it will not be easy.

A good test for any eventually proposed code is


demo ("isosurface")


Right now we use just enough gl_POLYGON_OFFSET so that the black borders of each patch object are distinct.  I've experimented with smaller values in the past and the boarders disappear behind the fill color of the patch object itself.


Rik <rik5>
Group administrator
Tue 07 Apr 2015 10:50:06 AM UTC, comment #2: 

I had this example tested on Matlab 2014a (Mac version). I also exported the printout with their various renderers (opengl, painters, zbuffer). The "painters" renderer didn't work and returned the following error message:


>> print ('-dpdf','-painters','patch4-paint')
Warning: RGB color data not yet supported in Painter's mode


They have the exact same patch outline issue in their implementation on-screen and printout as we do. As you'll notice their output seems to be raster based (see text pixels) except "painters" which shows real embedded text (but no patch).

I guess that's not a reason to not try to do a better job than Matlab.

(file #33577)

Pantxo Diribarne <pantxo>
Group Member
Mon 06 Apr 2015 04:44:29 AM UTC, comment #1: 

Can you get someone on the maintainers or help list to run the example in Matlab and upload the figures to this report.  It would be nice to see what we are trying to emulate.

Sample code:


clf;
t1 = (1/16:1/8:1)' * 2*pi;
t2 = ((1/16:1/16:1)' + 1/32) * 2*pi;
x1 = sin (t1) - 0.8;
y1 = cos (t1);
x2 = sin (t2) + 0.8;
y2 = cos (t2);
vert = [x1, y1; x2, y2];
fac = [1:8,NaN(1,8);9:24];
patch ('Faces',fac, 'Vertices',vert, ...
       'FaceVertexCData',[0, 1, 0; 0, 0, 1], 'FaceColor', 'flat');
%% Capture screenshot here and save to patch4_scrn.png

%% Now capture printout
print patch4_prnt.pdf



Rik <rik5>
Group administrator
Sun 05 Apr 2015 05:10:57 PM UTC, original submission:  

For this demo using the command "patch":


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


I'm seeing a blue hexadecagon fill drawn to the right having a closer-to-the-viewer depth and therefore overlaps the green octagon fill drawn to the left.  Both shapes have a black line outlining the fill, but the line for the green octagon is completely visible so appears to have a closer depth than the blue hexadecagon.  This is similar for both FLTK and Qt, but for gnuplot terminal the border of the green octagon is also behind the blue hexadecagon.

There is nothing in the demo code controlling the shape boundary separate from fill,


%!demo
%! %% Specify vertices and faces separately
%! clf;
%! t1 = (1/16:1/8:1)' * 2*pi;
%! t2 = ((1/16:1/16:1)' + 1/32) * 2*pi;
%! x1 = sin (t1) - 0.8;
%! y1 = cos (t1);
%! x2 = sin (t2) + 0.8;
%! y2 = cos (t2);
%! vert = [x1, y1; x2, y2];
%! fac = [1:8,NaN(1,8);9:24];
%! patch ('Faces',fac, 'Vertices',vert, ...
%!        'FaceVertexCData',[0, 1, 0; 0, 0, 1], 'FaceColor', 'flat');


so I assume the expectation is that the outline of the green octagon should also have a more-far-away view and be hidden by the blue hexadecagon and its outline.

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.


which may be a good place to start.  If the fills are all pushed backward, then perhaps all outlines appear more forward.

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 #34268:  foo.pdf added by muhali (3KiB - application/download)
file #34267:  foo.png added by muhali (10KiB - image/png)
file #33577:  ml_patch4.tar.gz added by pantxo (52KiB - application/x-tar)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (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
    2017-10-21 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-10-21 rik5 Item GroupIncorrect Result Matlab Compatibility
        StatusNone Ready For Test
    2015-06-19 muhali Attached File- Added foo.pdf, #34268
    2015-06-19 muhali Attached File- Added foo.png, #34267
    2015-04-07 rik5 Priority5 - Normal 3 - Low
        SummaryOpenGL based figure has incorrect element / object depth OpenGL patch outline has incorrect Z depth with respect to other patch fill colors
    2015-04-07 pantxo Attached File- Added ml_patch4.tar.gz, #33577

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code