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

 
 

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

Submitter:  Rik <rik5>
Submitted:  Tue 17 Sep 2013 03:28:41 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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.


graphics_toolkit fltk;
clf;
colormap ('default');
hold on;
plot (1:4, '-s');
imagesc (1 ./ hilb (4));
hold off;
print -dpng bottom.png
kids = get (gca, 'children')
set (gca, 'children', flipud (kids))
print -dpdf top.png


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>
Group 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>
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>
Group Member
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:


graphics_toolkit fltk
patch([0, 1, 1, 0], [0, 0, 1, 1], [0, 0, 0, 0], 'r')
patch([0, 1, 1], [0, 0, 1], [0, 0, 0], 'g')


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>
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>
Group Member
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>
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:


graphics_toolkit fltk;
clf;
colormap ('default');
hold on;
plot (1:4, '-s');
imagesc (1 ./ hilb (4));
hold off;


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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

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

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2014-04-15 rik5 Attached File- Added marker_img.cset, #31174
        StatusNone Ready For Test
    2013-11-27 rik5 Dependencies- bugs #40722 is dependent
    2013-09-17 rik5 Attached File- Added fltk.png, #29164
        Attached File- Added gnuplot.png, #29165

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code