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.
|
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.
|
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.
|
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:
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.
|
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.
|
Wed 04 Feb 2015 11:12:26 AM UTC, comment #8:
Hi,
@Rik: maybe we used to but AFAICS we currently don't use GL2PS_POLYGON_OFFSET_FILL. If I modify gl2ps-renderer this way:
The following scripts renders the colorbar perfectly:
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?
|
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
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.
|
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.
I tried to play with the value of the offset in opengl_renderer::draw_axes_planes, with no success.
|
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.
|
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
the image appears in test3.eps (in contrast to drawnow ("eps", "cat > test3.eps"))
|
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.
|
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:
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.
|
Wed 28 Jan 2015 10:46:22 PM UTC, comment #1:
Hi,
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?
|
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');
saveas(h,'test.png')
This produces the attached plot.
|