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 07 Apr 2017 02:49:58 PM UTC  
 
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 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)

Thu 10 Aug 2017 05:36:42 AM UTC, comment #19:

What is a good way to benchmark?

I tried

But I don't see much difference between the layer3 and layer6 patches in terms of performance.

For the time being I pushed the latest layer6 patch because there are new bug reports about the behavior with light being incorrect.

Rik <rik5>
Project Administrator
Tue 25 Jul 2017 01:38:03 PM UTC, comment #18:

@Rik: Yes what you mention was expected but I thought the performance penalty was negligible. In fact it is not, rendering becomes up to 2 times slower for axes with ~200 objects.

I attached a new patch which is more elegant: the dimensionality of children objects is determined by comparing upper and lower z limits. The only drawback is that z limits have to be checked even when zlimmode is manual. I added a FIXME note about that but I think it is acceptable.

(file #41331)

Pantxo Diribarne <pantxo>
Project Member
Sat 22 Jul 2017 03:24:46 AM UTC, comment #17:

I tried the patch and it works, however it looks like there is a performance penalty. The function get_is2D is called from draw_axes which eventually requires a recursive search through the graphic objects to find any 3-D objects. I inserted code to see how often draw_axes is called and it is quite frequent. Try this patch

After re-compiling try some plot commands and try toggling the grid or panning the plot. There are ~2 has_3D_primitive calls for every draw_axes call.

Rik <rik5>
Project Administrator
Thu 20 Jul 2017 09:22:24 PM UTC, comment #16:

I attached a cset that fixes the regression for me.

(file #41268)

Pantxo Diribarne <pantxo>
Project Member
Tue 06 Jun 2017 05:32:39 PM UTC, 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 04 Jun 2017 09:07:57 PM UTC, 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 04 Jun 2017 02:55:21 PM UTC, 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 04 Jun 2017 02:54:44 PM UTC, 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 04 Jun 2017 12:34:01 PM UTC, comment #11:

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

Pantxo Diribarne <pantxo>
Project Member
Sun 28 May 2017 12:40:25 PM UTC, 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 28 May 2017 04:39:38 AM UTC, 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 18 May 2017 05:05:55 PM UTC, 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 12 Apr 2017 09:48:18 PM UTC, 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 07 Apr 2017 10:30:56 PM UTC, 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 07 Apr 2017 10:11:57 PM UTC, comment #5:

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

Muhali <muhali>
Fri 07 Apr 2017 09:37:07 PM UTC, 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 07 Apr 2017 09:09:59 PM UTC, 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 07 Apr 2017 05:24:38 PM UTC, 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 07 Apr 2017 05:09:03 PM UTC, 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 07 Apr 2017 02:49:58 PM UTC, 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 #41331:  layer6.patch added by pantxo (7KiB - text/x-patch)
file #41268:  layer3.patch added by pantxo (5KiB - text/x-patch)
file #40803:  layer.patch added by pantxo (5KiB - text/x-patch)
file #40382:  depth.patch added by pantxo (2KiB - 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 (14KiB - image/png)
file #40322:  aboxplot.m added by rik5 (10KiB - text/x-objcsrc)
file #40323:  foo.1.3.8.png added by rik5 (13KiB - image/png)
file #40308:  foo.png added by muhali (12KiB - image/png)
file #40309:  aboxplot.m added by muhali (10KiB - text/x-objcsrc)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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 20 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 10 Aug 2017 05:01:26 AM UTCrik5Dependencies-=>bugs #51716 is dependent
    Tue 25 Jul 2017 01:38:03 PM UTCpantxoAttached File-=>Added layer6.patch, #41331
    Thu 20 Jul 2017 09:22:24 PM UTCpantxoAttached File-=>Added layer3.patch, #41268
    Sun 04 Jun 2017 09:07:57 PM UTCpantxoStatusPatch Reviewed=>Fixed
      Open/ClosedOpen=>Closed
    Sun 28 May 2017 12:40:25 PM UTCpantxoAttached File-=>Added layer.patch, #40803
    Thu 18 May 2017 05:05:55 PM UTCrik5StatusPatch Submitted=>Patch Reviewed
    Wed 12 Apr 2017 09:48:18 PM UTCpantxoAttached File-=>Added depth.patch, #40382
      StatusConfirmed=>Patch Submitted
    Fri 07 Apr 2017 09:37:07 PM UTCrik5Attached 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 07 Apr 2017 09:09:59 PM UTCrik5Attached 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 07 Apr 2017 05:09:03 PM UTCrik5StatusNone=>Need Info
    Fri 07 Apr 2017 02:49:58 PM UTCmuhaliAttached 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