bugGNU Octave - Bugs: bug #44111, Images not printed when there's a...


bug #44111: Images not printed when there's a 3D axes in the figure

Submitted by:  None
Submitted on:  Wed 28 Jan 2015 08:18:50 PM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Geoffrey Mellar Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  3.8.2
Operating 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)

Sat 14 Feb 2015 05:36:12 PM UTC, comment #13: 

Okay, I applied the change here (http://hg.savannah.gnu.org/hgweb/octave/rev/1a6fa5a523e4).  Closing report.

Rik <rik5>
Project Administrator
Sat 14 Feb 2015 03:28:52 PM UTC, comment #12: 

@Rik: I finally wrote to the gl2ps maintainer. I had problems to subscribe to their list so the mail was private but to sum up: yes thats the way we should use gl2psEnable/Disable, i.e. each time we change the offset we should enable disable. However, there is indeed a problem in their current implementation, and only the last offset is taken into account for the whole scene.
My approach would thus be : "if it incidentally work lets go ahead :-), anyway that's the way we should go when the issue is fixed". The maintainer asked me if I could provide a patch so that all offsets are stored in the buffer, which I will do ASAP (it's just a matter of reproducing line stipple behavior which is ok).

Finally, I won't have access to my dev machine till the end of the week end so go ahead.

Pantxo Diribarne <pantxo>
Project Member
Fri 13 Feb 2015 11:05:18 PM UTC, comment #11: 

@Pantxo: I finally reviewed this and I like it a lot.  It also clears up bug #44125 on Windows systems.  You can apply the change, but if you are busy on the annotation patch or another one then I can do it.  Just let me know.

Rik <rik5>
Project Administrator
Thu 05 Feb 2015 09:55:44 AM UTC, comment #10: 

@Rik: you are right. gl2psEnable  doc says:

"The value of the offset is taken as the current value of the
corresponding OpenGL offset (set with glPolygonOffset)".

As I understand, PolygonOffset data, that we set in our gl-renderer, are not written in the feedback buffer (see [1]) that gl2ps will parse/interpret/draw when we call gl2psEndPage(), i.e. after all our drawing have been done. As a consequence gl2ps has to force some additional informations to be written "live" in the feedback buffer while we are "drawing". That is why we should gl2psEnable/Disable each time we change the offset.

The above could be done through something like:

gl2ps_renderer::set_polygon_offset (bool on, float offset)
  if (on)
      opengl_renderer::set_polygon_offset (on, offset);
      gl2psEnable (GL2PS_POLYGON_OFFSET_FILL);
      gl2psDisable (GL2PS_POLYGON_OFFSET_FILL);
      opengl_renderer::set_polygon_offset (on, offset);

By looking at the gl2ps.c code I think it is how gl2psEnable was intended to be used. Unfortunately, I think that gl2ps currently only stores the values of the offset (factor/unit) that was in place the last time you called "gl2psEnable (GL2PS_POLYGON_OFFSET_FILL);", before gl2psEndPage(). If you think it is worth I can ask for details on gl2ps mailing list. Thoughts?

[1] http://bittar.free.fr/OpenGL/opengl/glPolygonOffset.html : glPolygonOffset has no effect on depth coordinates placed in the feedback buffer.

Pantxo Diribarne <pantxo>
Project Member
Wed 04 Feb 2015 04:46:05 PM UTC, comment #9: 

@Pantxo: It may be that we have been using gl2ps incorrectly for a long time.  The current strategy is to create a GL context with gl2ps and then use the regular draw routines in gl-render.cc to draw the object.  Finally the GL context is printed out by gl2ps.  The code in gl-render.cc, however, does lots of option checking and option setting using glEnable rather than gl2psEnable.  This might be a source of the problem.  Maybe we were hoping that glEnable within the gl2ps context was overloaded and that it calls gl2psEnable.  I'm not sure.  What I would hate to do is have to duplicate the entire gl-render.cc file and replace every occurrence of glXXXX with gl2psXXXX.

It would be best to find out if we are doing this wrong rather than unconditionally enable GL2PS_POLYGON_OFFSET_FILL.

Rik <rik5>
Project Administrator
Wed 04 Feb 2015 11:12:26 AM UTC, comment #8: 


@Rik: maybe we used to but AFAICS we currently don't use GL2PS_POLYGON_OFFSET_FILL. If I modify gl2ps-renderer this way:

diff -r fd9a5da4afff libinterp/corefcn/gl2ps-renderer.cc
--- a/libinterp/corefcn/gl2ps-renderer.cc        Tue Feb 03 12:51:54 2015 +0100
+++ b/libinterp/corefcn/gl2ps-renderer.cc        Wed Feb 04 12:00:24 2015 +0100
@@ -112,6 +112,7 @@
           if (ret == GL2PS_ERROR)
             error ("gl2ps-renderer::draw: gl2psBeginPage returned GL2PS_ERROR");
           old_print_cmd = print_cmd;
+          gl2psEnable (GL2PS_POLYGON_OFFSET_FILL)
           opengl_renderer::draw (go);

The following scripts renders the colorbar perfectly:

sombrero (); colorbar (); print -dpng toto.eps

So it looks like a very good idea Rik. Am I correct that we unconditionally want to use this feature (BSP sort or not)? Should I go ahead with this change?

Pantxo Diribarne <pantxo>
Project Member
Mon 02 Feb 2015 05:35:38 PM UTC, comment #7: 

Images specifically set the axis 'layer' property to 'top' so that ticklines appear on top of the image.  You can use

set (gca, 'layer', 'bottom')

to send the axes object to the bottom of the stack.  However, it still didn't produce the correct printout for me.

This is probably some issue with gl2ps not completely implementing the OpenGL specification.  Octave uses GL2PS_POLYGON_OFFSET_FILL to slightly displace objects like a 2-D image and the 2-D background axes filled patch which are both at Z == 0.  In 3-D mode it may be that gl2ps only pays attention to Z value and ignores the slight bump we give to the axes object.  In that case, it's probably somewhat random which one is placed on top in the output stream.

Rik <rik5>
Project Administrator
Sat 31 Jan 2015 02:57:44 PM UTC, comment #6: 

If it may help, it is the axes background plane that is detected by GL2PS_BSP_SORT as being over the image.

hax1 = axes ('position', [.1 .1 .3 .8])
view (3);
hax2 = axes ('position', [.6 .1 .3 .8])
image ()
set (gca, "color", "none")
print test1.png

I tried to play with the value of the offset in opengl_renderer::draw_axes_planes, with no success.

Pantxo Diribarne <pantxo>
Project Member
Fri 30 Jan 2015 06:20:32 PM UTC, comment #5: 

Yes, that's what I saw.

My concern is that it used to work well in 3.8.1 (at least on my linux mint install) and I don't see any modification that affects the sorting algorithm since the release of 3.8.1.

Pantxo Diribarne <pantxo>
Project Member
Fri 30 Jan 2015 05:47:46 PM UTC, comment #4: 

Looks like a problem with gl2ps culling and/or the used sorting algorithm.

If I force GL2PS_SIMPLE_SORT with

drawnow ("epsis2d", "cat > test3.eps")

the image appears in test3.eps (in contrast to drawnow ("eps", "cat > test3.eps"))

Andreas Weber <andy1978>
Project Member
Thu 29 Jan 2015 10:13:44 PM UTC, comment #3: 

Retitling the bug report to better describe the issue and changing the category as gnuplot works well with the original example.

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Jan 2015 10:04:25 PM UTC, comment #2: 

Thanks for the data. I can confirm the issue in dev (default 19630:e68267373191), except in my build the colorbar is totally empty in the output file.

The following script also triggers the issue for me in dev:

hax1 = axes ('position', [.1 .1 .3 .8])
hax2 = axes ('position', [.6 .1 .3 .8])
image ()
print test1.png
view (hax1, 3)
print test2.png

When the first created axes view is 3D, the second axes image is not printed in the output file. On-screen the image looks good.

Pantxo Diribarne <pantxo>
Project Member
Wed 28 Jan 2015 10:46:22 PM UTC, comment #1: 


Thanks for your bug report. The example you provided can't be reproduced without the data file. Can you produce a minimal example script or attach the file?

Pantxo Diribarne <pantxo>
Project Member
Wed 28 Jan 2015 08:18:50 PM UTC, original submission:  

Following code:

data = load('parameter_10/500000.txt');
m = 40;
n = 40;
X = reshape(data(:,1),m,n);
Y = reshape(data(:,2),m,n);
Z = reshape(data(:,3),m,n);
colormap ('default');
h = surf(X,Y,Z);
colorbar ('westoutside')
title ('Kohonen');

This produces the attached plot.



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

Attach Files:

Attached Files
file #32935:  500000.txt added by None (42KiB - text/plain - Input data file for reproducing the error)
file #32929:  test.png added by None (317KiB - image/png)


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by andy1978
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

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

    Only project members can vote.




    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-16 rik5 Open/ClosedOpen => Closed
    2015-02-14 rik5 StatusConfirmed => Fixed
    2015-02-13 rik5 Dependencies- => bugs #44125 is dependent
    2015-02-02 rik5 StatusNone => Confirmed
    2015-01-30 andy1978 Carbon-Copy- => Added andy1978
    2015-01-29 pantxo CategoryPlotting => Plotting with OpenGL
        Summary => Images not printed when there's a 3D axes in the figure
    2015-01-29 pantxo Summarycolorbar overlap =>
    2015-01-29 None Attached File- => Added 500000.txt, #32935
    2015-01-28 None Attached File- => Added test.png, #32929

    Back to the top

    Powered by Savane 3.5