bugGNU Octave - Bugs: bug #50750, OpenGL: Lines always appear above...

 
 

bug #50750: OpenGL: Lines always appear above patches for 2-D plots with zdata == []

Submitted by:  Muhali <muhali>
Submitted on:  Fri Apr 7 14:49:58 2017  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Tue Jun 6 17:32:39 2017, comment #15:

I just noticed that now 2D representations of 3D scenes fail on-screen and in printout: see e.g. demo light 2.

The reason is that we currently determine wether an axes is 2D using only the "view" property, which may be setup as 2D even when there are 3D primitives in the axes. I'll provide a fix ASAP.

Pantxo Diribarne <pantxo>
Project Member
Sun Jun 4 21:07:57 2017, comment #14:

Thanks Rik, I pushed the patched here:

http://hg.savannah.gnu.org/hgweb/octave/rev/06805aabbdd1

Closing report as fixed.

Pantxo Diribarne <pantxo>
Project Member
Sun Jun 4 14:55:21 2017, comment #13:

I did test it quickly last week. I think it is worth applying as it narrows the number of cases where Octave is wrong to something smaller.

Rik <rik5>
Project Administrator
Sun Jun 4 14:54:44 2017, comment #12:

I did test it quickly last week. I think it is worth applying as it narrows the number of cases where Octave is wrong to something smaller.

Rik <rik5>
Project Administrator
Sun Jun 4 12:34:01 2017, comment #11:

@Rik: did you get a chance to test the patch?

Pantxo Diribarne <pantxo>
Project Member
Sun May 28 12:40:25 2017, comment #10:

@Rik: I attached an updated cset that takes care of the "layer" property. Unfortunately gl2ps does not provide a way to change the sorting algorythm on a per viewport basis. So after the patch, the bug still stands for printed output if there is a 3D axes among other 2D axes e.g

(file #40803)

Pantxo Diribarne <pantxo>
Project Member
Sun May 28 04:39:38 2017, comment #9:

@Pantxo: Ping! Just checking that you saw my note from May 18th. It looks to me like if we are going to support the 'layer' property of axes, and use this patch, that we would need to change the order of drawing axes and children in gl-render.cc.

Rik <rik5>
Project Administrator
Thu May 18 17:05:55 2017, comment #8:

@Pantxo: I tried your patch and it definitely resolves the issues experienced. I think it is probably the right direction, but it needs some refinement. On 3-D plots that are presented as 2-D plots, such as contourf or autumn, the axes ticks are now underneath the patch object rather than above.

Try

to see what I mean.

The problem seems to be that the axes "layer" property which can be "top" or "bottom" is no longer working.

Rik <rik5>
Project Administrator
Wed Apr 12 21:48:18 2017, comment #7:

"demo hold 6" also shows the problem (see here: https://josoansi.de/octave_plot_compare/compare_plot_demos_03.html)

I attached a simple preliminary patch that fixes this bug and the "hold" demo, but didn't test it thoroughly against regressions.

(file #40382)

Pantxo Diribarne <pantxo>
Project Member
Fri Apr 7 22:30:56 2017, comment #6:

It's all the same issue. Every line is being displayed above the patch object. That includes the ones you want (circle and horizontal line) and the ones you don't want (vertical line).

Rik <rik5>
Project Administrator
Fri Apr 7 22:11:57 2017, comment #5:

but note that the horizontal line and the circle (median and mean I guess) SHOULD be visible.

Muhali <muhali>
Fri Apr 7 21:37:07 2017, comment #4:

I added a simpler example of a single line and a rectangle object (tst_rect.m). It shows that lines are always on top of patches for 2-D OpenGL plots.

(file #40324)

Rik <rik5>
Project Administrator
Fri Apr 7 21:09:59 2017, comment #3:

I changed the sample test file to not load the package nan. This script is attached to the bug report as tst_boxplot.m. It also requires a version of 'aboxplot.m' that does not use nanmean. That is also uploaded.

Using Qt, I find that the dots are visible onscreen. This probably indicates that the effect depends on the particular version of OpenGL on a user's computer and whether it is being hardware accelerated or not.

When I print, I get two different results depending on whether gl2ps version 1.3.9 or 1.3.8 is used. With the more recent version, 1.3.9, the print out matches the screen, but that does have the dots on it.

I'm attaching the two plots: foo.1.3.9.png and foo.1.3.8.png.

(file #40320, file #40321, file #40322, file #40323)

Rik <rik5>
Project Administrator
Fri Apr 7 17:24:38 2017, comment #2:

Yes, no dots (screenshot) is the figure window from the plot command and is as expected, and foo.png is the incorrect print output with the dots visible.

Muhali <muhali>
Fri Apr 7 17:09:03 2017, comment #1:

Just checking, foo.png is output from Octave which is incorrect. And Screenshot.png is what the output should look like?

Rik <rik5>
Project Administrator
Fri Apr 7 14:49:58 2017, original submission:

The following is adapted from the aboxplot function (attached)

In the box there should be no dots visible, as in Matlab. In octave I get

with qt: dots not in plot but in print (see attached plot and print)

with fltk: dots in plot and print

with gnuplot: no dots in plot and print

Muhali <muhali>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #40803:  layer.patch added by pantxo (5kB - text/x-patch)
file #40382:  depth.patch added by pantxo (2kB - text/x-patch)
file #40324:  tst_rect.m added by rik5 (244B - text/x-objcsrc)
file #40320:  tst_boxplot.m added by rik5 (209B - text/x-objcsrc)
file #40321:  foo.1.3.9.png added by rik5 (14kB - image/png)
file #40322:  aboxplot.m added by rik5 (10kB - text/x-objcsrc)
file #40323:  foo.1.3.8.png added by rik5 (13kB - image/png)
file #40308:  foo.png added by muhali (12kB - image/png)
file #40309:  aboxplot.m added by muhali (10kB - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by pantxo (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by muhali (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 17 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jun 4 21:07:57 2017pantxoStatusPatch Reviewed=>Fixed
      Open/ClosedOpen=>Closed
    Sun May 28 12:40:25 2017pantxoAttached File-=>Added layer.patch, #40803
    Thu May 18 17:05:55 2017rik5StatusPatch Submitted=>Patch Reviewed
    Wed Apr 12 21:48:18 2017pantxoAttached File-=>Added depth.patch, #40382
      StatusConfirmed=>Patch Submitted
    Fri Apr 7 21:37:07 2017rik5Attached File-=>Added tst_rect.m, #40324
      StatusNeed Info=>Confirmed
      Summarydots behind box=>OpenGL: Lines always appear above patches for 2-D plots with zdata == []
    Fri Apr 7 21:09:59 2017rik5Attached File-=>Added tst_boxplot.m, #40320
      Attached File-=>Added foo.1.3.9.png, #40321
      Attached File-=>Added aboxplot.m, #40322
      Attached File-=>Added foo.1.3.8.png, #40323
    Fri Apr 7 17:09:03 2017rik5StatusNone=>Need Info
    Fri Apr 7 14:49:58 2017muhaliAttached File-=>Added Screenshot from 2017-04-07 12-45-57.png, #40307
      Attached File-=>Added foo.png, #40308
      Attached File-=>Added aboxplot.m, #40309

    Back to the top


    Powered by Savane 3.1-cleanup1