bugGNU Octave - Bugs: bug #40054, FLTK: incorrect Z-order stacking...

 
 

bug #40054: FLTK: incorrect Z-order stacking for markers and images

Submitted by:  Rik <rik5>
Submitted on:  Tue 17 Sep 2013 03:28:41 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
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)

Sat 19 Apr 2014 01:38:25 AM UTC, comment #8:

I pushed the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/75ec138ba53b). Closing report.

Rik <rik5>
Project Administrator
Tue 15 Apr 2014 09:05:57 PM UTC, comment #7:

I'm attaching a patch which fixes the problem for me. When there is no zdata (2-D plot) the markers are now placed at Z=0 rather than Z = 1/n where n is the number of markers. Because the OpenGL line object is drawn first, the marker appears on top of the line as is expected. The patch doesn't appear to upset other aspects of plotting. If someone else can test and verify that this doesn't change other plotting behaviors then I will push it.

(file #31174)

Rik <rik5>
Project Administrator
Thu 19 Sep 2013 03:16:00 AM UTC, comment #6:

How does gl2ps handle this? I just tried the original code, and then flipped the stacking order, as shown below.

The png files are correct without the artifact of the marker alone being out of Z-order.

If we were to skip using the Z-delta spacing in 2-D mode, what files need to be changed? Is it something easy to try, or a huge re-code? If small, I'd like to try it and see if it fixes the problem.

Rik <rik5>
Project Administrator
Tue 17 Sep 2013 06:48:30 PM UTC, comment #5:

The problem you point out also exists. I believe there's a bug opened about it. However that specific problem can be worked around by doing part of the transformation (the pre-scaling/-translation) in octave. Obviously this implies loosing a bit of the GPU acceleration, but I suppose that's ok, we're not talking about a 3D first-shooter game here :).

Michael Goffioul <goffioul>
Project Member
Tue 17 Sep 2013 06:41:22 PM UTC, comment #4:

I understand. I was just pointing out other
issues due to limited precision of float.

Michael Godfrey <godfrey>
Tue 17 Sep 2013 06:21:57 PM UTC, comment #3:

I'm not even talking about the X/Y/Z pre-scaling issue here. I'm talking about the precision of the 3D rotation computed by OpenGL (we're not going to do that ourselves).

For instance:

Then try to rotate the plot in 3D and you'll start seeing visual artefacts, sometimes the green patch will appear on top of the red one, sometimes not, sometimes it will only be partial...

This kind of artefact also occurs within a patch object, between the edges and the filling. OpenGL allows to introduce artificial offset between the 2 by using glPolygonOffset. This works fine, as long as you don't have another overlapping object/polygon in the same Z plane. If you do, you start to have unexpected behavior (like some parts of an object, markers, being on top of another object, while other parts, lines, are under it).

Michael Goffioul <goffioul>
Project Member
Tue 17 Sep 2013 05:50:36 PM UTC, comment #2:

The use of float in OpenGL is a pretty basic problem.
Since the data must be rescaled inside OpenGL in any
case, they could have allowed higher precision and then
rescaled before using the hardware which currently is
only float.

However, it appears that some of the problems described
in this report could be handled more smoothly if the
Octave code did a rescaling to some standard array
dimensions which are within float. Then the offsets
would be easier to deal with and the problem of user
supplied data being outside the float range would go
away.

People with more detailed knowledge of the internals of
OpenGL may have a better idea.

Michael Godfrey <godfrey>
Tue 17 Sep 2013 03:46:13 PM UTC, comment #1:

Stacking is definitely a problem in OpenGL, for objects that lies in the same Z-plane. Due to limited precision (OpenGL uses float), artefacts can appear, especially when you start rotating a plot.

I'm not even sure there's a solution for that problem, at least an easy one. To make sure that objects appear more or less correctly on screen, some offset is applied in OpenGL, but then you get unexpected result if another object lies in the same Z plane, like here.

For instance, to make sure the edges of a filled patch are visible, the "filling" is slightly offset (along Z). Similar offset is (or can be, I don't remember exactly) used to make sure markers appear on top of a line, and not under it. This offset is of the order of OpenGL precision, but it's enough to create unexpected result when multiple objects lie in the same plane.

Maybe one trade-off could be to use these slight offset only in 3D mode and not in 2D.

Michael Goffioul <goffioul>
Project Member
Tue 17 Sep 2013 03:28:41 PM UTC, original submission:

The following code plots a line and an image on the same plot. According to the plotting rules, the first-listed child of the current axis should be on top in the Z-order stacking. This works correctly for the line portion of a line object, but the markers are incorrectly placed at the top of the Z-order.

Sample code:

I've attached two plots which show the difference between gnuplot, which gets it right, and fltk. I had to take a screen capture for the FLTK image because the image is printed correctly, just not displayed on a monitor correctly.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #31174:  marker_img.cset added by rik5 (900B - application/octet-stream)
file #29164:  fltk.png added by rik5 (11kB - image/png)
file #29165:  gnuplot.png added by rik5 (13kB - image/png)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by rik5 (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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 19 Apr 2014 01:38:25 AM UTCrik5StatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 15 Apr 2014 09:05:57 PM UTCrik5Attached File-=>Added marker_img.cset, #31174
      StatusNone=>Ready For Test
    Wed 27 Nov 2013 04:45:00 PM UTCrik5Dependencies-=>bugs #40722 is dependent
    Tue 17 Sep 2013 03:28:41 PM UTCrik5Attached File-=>Added fltk.png, #29164
      Attached File-=>Added gnuplot.png, #29165

    Back to the top


    Powered by Savane 3.1-cleanup