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.
|
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.
|
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.
|
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.
|
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.
|
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
the edge becomes hidden. And interestingly, it is also hidden in the pdf output but not in the png (see attached).
(file #34267, file #34268)
|
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
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.
|
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:
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)
|
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:
|
Sun 05 Apr 2015 05:10:57 PM UTC, original submission:
For this demo using the command "patch":
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,
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:
which may be a good place to start. If the fills are all pushed backward, then perhaps all outlines appear more forward.
|