bugGNU Octave - Bugs: bug #34523, linestyle not always used for 3D...

 
 

bug #34523: linestyle not always used for 3D plots (gnuplot)

Submitter:  Peter Jeffris <jeffris>
Submitted:  Tue 11 Oct 2011 12:22:40 AM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Peter Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Sep 2016 12:16:11 AM UTC, comment #25: 

This seems to be related to both the terminal selected and the version of gnuplot.  I don't think Octave is doing anything wrong at this point so I'm going to close this report.

Rik <rik5>
Group administrator
Wed 09 Mar 2016 12:57:05 PM UTC, comment #24: 

Rik,

Have you tried different terminal types with 2D plots? Below is a script that works for me. You'll need to delete "aqua".


1;

function do_plot (term)
  if (nargin < 1)
    term = "aqua";
  endif
  setenv ("GNUTERM", term);
  persistent x y
  if (isempty (x))
    x = 1:4;
    y = rand (4);
  endif
  h = plot (x, y(1,:), "-", ...
            x, y(2,:), "--", ...
            x, y(3,:), "-.", ...
            x, y(4,:), ":");
  set (h, "linewidth", 2);
  drawnow ()
end

graphics_toolkit gnuplot

figure (1)
do_plot aqua
figure (2)
do_plot x11
figure (3)
do_plot qt
figure (4)
do_plot wxt


I no longer have a gnuplot 4.6 to run. For gnuplot 5, this produces different linestyles for the terminals. However, I have a patch that fixes that (it is attached).

(file #36579)

Ben Abbott <bpabbott>
Group Member
Mon 29 Feb 2016 03:36:26 AM UTC, comment #23: 

I think this is a good start.  I applied the patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/21c3641422e0).

The Summary of this bug, FaceColor for surf with gnuplot, has been fixed.  However, there are now some issues with linestyle for 3-D plots.

Using the test code:


graphics_toolkit("gnuplot");
figure();
[x, y] = meshgrid (-2:.2:2);
t = linspace (-2, 2, 10);
z = (1+x.*y).*(x+y);
h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);
hold on
plot3 (t, t, t)

set(h, 'edgecolor', 'r')
set(h, 'linewidth', 3)
set(h, 'linestyle', ':')
set(h, 'facecolor', 'y')


With gnuplot 5.0.1, the linestyles "--", "-." don't seem to work.

With gnuplot 4.6.6, all linestyles are rendered as "-" (solid).  If I try to turn off lines completely with "set (h, 'linestyle', 'none'" I get a bunch of errors.


splot "-" binary format='%float64' record=21x21 using ($1):($2):($3):($4) title "" with pm3d linecolor rgb variable , "-" binary format='%float64' record=21x21 using ($1):($2):($3) title "" with  linetype 9 , "-" binary format='%float64' record=10 using ($1):($2):($3) title "" with lines linetype 11 ;
            octave:15>                                                                                                                                                                                                           ^
         line 0: unrecognized plot type


Note that the linestyles work correctly for a 2D plot such as "plot (1:10, 'o:')"

Rik <rik5>
Group administrator
Mon 29 Feb 2016 02:07:49 AM UTC, comment #22: 

@Dan/Rik,

One of two of my patches conflicted with this sone. It only took be about an hr to clean up Dan's patch so that it would apply. I'm attaching the updated version.

I've only done a minimal amount of testing. 2D plots work for me, but the linestyles rendered do not match up across all terminals (bug #46886). I haven't tested the modified patch to see if it works as Dan intended.

(file #36502)

Ben Abbott <bpabbott>
Group Member
Thu 18 Feb 2016 10:10:01 PM UTC, comment #21: 

@Dan: I went to try and test the cset but it no longer applies cleanly.  Do you have time to refresh it so I can test it and apply it before more code changes happen?

Rik <rik5>
Group administrator
Tue 07 Jul 2015 06:18:37 PM UTC, comment #20: 

This changeset is ready for testing.

Dan Sebald <sebald>
Sat 27 Jun 2015 07:04:27 PM UTC, comment #19: 

Regarding post https://savannah.gnu.org/bugs/?34523#comment18, I've a good example that the depth order is missing, so I'm certain there is a problem.  I'll file a bug report with the gnuplot project.

Dan Sebald <sebald>
Sat 27 Jun 2015 04:19:42 AM UTC, comment #18: 

When testing, please change the mesh color to something light and tell me if it looks as though the line is erroneously appearing behind mesh lines.  In some intersections, that looks to be the case for me.  I'll report that as a bug...my thinking is that even though line removal is correct, the line segments still need to be plotted from furthest back in the viewspace to the nearest.  Otherwise, the drawing of lines will bleed over a line it may be behind.

Dan Sebald <sebald>
Sat 27 Jun 2015 04:14:31 AM UTC, comment #17: 

All right.  I think I have something that works with gnuplot 4.6 up to the latest development version.  This is a pretty significant variation on the previous patch, so some testing will be helpful.  I've changed enough with respect to gnuplot hidden3d usage that it could break behavior somewhere else, but I'm hoping not much.

I discarded the "borders" approach to adding mesh lines on surfaces and instead just add another separate plot sub-command for the lines, using hidden3d mode (with the addition of "front" and "nooffset" to the hidden3d specification).  That improves the program flow some, in addition to achieving the hidden line. 

However, I've found that "linestyle" attributes don't hold in gnuplot's hidden3d mode--when they do hold in non-hidden3d mode and specifications like "linecolor" apply in both modes.  I was a bit disappointed by that and complained to get a fix.  On the other hand, "linetype" does work with hidden3d mode.  But linetype holds the important line patterns for version 4.6.  So to avoid overwriting those line patterns, I introduced an offset of 8 into the linetype/style definitions.  (I.e., instead of seeing "set linestyle 1...", "set linestyle 2..." and so on in the gnuplot code, one will see "set linestyle 9...", "set linestyle 10..." and so on.


(file #34329)

Dan Sebald <sebald>
Wed 24 Jun 2015 11:09:30 PM UTC, comment #16: 

OK.  I had looked at the latest 5.1 documentation and it doesn't list "border" in the options either.  (It is a subtopic.  The hidden3d/pm3d documentation is spread out over several areas.)  So I was hoping that "border" had been introduced prior to the linetype, etc.  Guess not.

I've gnuplot 4.6 compiled here.  It doesn't seem to have any of the "set pm3d border/linetype/linecolor/etc" options.  In fact, I don't understand why this "border" option was added.  It appears that gnuplot can add the lines with something like:

set hidden3d front
splot x*y with pm3d, x*y with lines

which should handle the hidden 3d removal of lines.

I'm going to take a couple days to inquire with gnuplot developers what "border" is for.  If there isn't a salient reason for that, I think I'll try to rework the changeset slightly to try avoiding its and include another set of data for the mesh lines.

Dan Sebald <sebald>
Wed 24 Jun 2015 08:39:20 PM UTC, comment #15: 

Still generates an error, this time at the keyword border.


set pm3d explicit at s hidden3d border linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                ^
         line 0: invalid pm3d option


I don't think "border" is supported for pm3d in 4.6, at least according to the docs I quoted in comment #13.



Rik <rik5>
Group administrator
Wed 24 Jun 2015 05:53:25 PM UTC, comment #14: 

Sorry about that.  The 'border' was being conditioned out unnecessarily.  New changeset attached.


(file #34308)

Dan Sebald <sebald>
Wed 24 Jun 2015 04:47:44 PM UTC, comment #13: 

@Dan: I applied the last patch in comment #12 and I still get an error under gnuplot 4.6.6 and gnuplot 4.6.7.


h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);

gnuplot> set pm3d explicit at s hidden3d  linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                          ^
         line 0: invalid pm3d option


I commented out "linetype 1" in the issued command, but then it just fails at "linecolor".

The gnuplot documentation for pm3d using version 4.6 (http://gnuplot.info/docs_4.6/gnuplot.pdf) says:


set pm3d {
{ at <position> }
{ interpolate <steps/points in scan, between scans> }
{ scansautomatic | scansforward | scansbackward | depthorder }
{ flush { begin | center | end } }
{ ftriangles | noftriangles }
{ clip1in | clip4in }
{ corners2color { mean|geomean|median|min|max|c1|c2|c3|c4 } }
{ hidden3d {<linestyle>} | nohidden3d }
{ implicit | explicit }
{ map }
}


So it appears that a linestyle is accepted.  But maybe it means that you have to reference a style that was already created rather than make one on the fly?



Rik <rik5>
Group administrator
Tue 23 Jun 2015 09:22:48 PM UTC, comment #12: 

gnuplot documentation indicates the 'linetype' feature appeared in 4.6, so I added that to the gnuplot-has-feature code and made a very small change to the gnuplot_linetype function--basically adding another condition to an if-elseif-else statement.

I've looked into the hidden line removal and there is quasi-support for such a thing with the "pm3d" surface.  Using the command

set hidden3d front

will plot the surface first, and then everything else on top of that.  Then if all the lines are using the hidden3d algorithm, it does look like proper hidden3d surface (provided the surface doesn't have any overlapping elements).

Unfortunately, I think there is a bug in the color operation for lines under the hidden3d mode.  I will let you experiment, and then we can decide to either put the "set hidden3d front" statement in the gnuplot stream, have a bad plot and wait for gnuplot to catch up...or wait for gnuplot to be fixed and then come back to revisit the hidden3d line removal.

To experiment, generate the test surface plot as before.  Then use the Octave command:

drawnow ("qt", "/dev/null", false, "foo1.gp");

(The terminal can be "x11" if you wish, and in fact it produces different behavior so you may want to test that as well.)  Next, edit the file 'foo1.gp' and place after the "unset hidden3d" line "set hidden3d front;", i.e.,

unset hidden3d
set hidden3d front;

Launch gnuplot and enter "load 'foo1.gp'".  On my system, the surface lines are missing (qt) or appear white (x11).



(file #34301)

Dan Sebald <sebald>
Fri 19 Jun 2015 04:11:27 PM UTC, comment #11: 

@Dan: Overall this patch seems to be a big improvement, and I'm inclined to apply it to the default branch.  I'm also attaching the results of the surf plot commands for fltk and gnuplot.  There is still a difference in how much of the line is displayed, but we can't always have everything.

One last issue is that I still get a warning from gnuplot


h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);

gnuplot> set pm3d explicit at s hidden3d  linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                          ^
         line 0: invalid pm3d option


gnuplot> set pm3d explicit at s hidden3d  linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                          ^
         line 0: invalid pm3d option


The caret marker, '^', is pointing to the "linetype" keyword.  Can we use _gnuplot_version_ or some other mechanism to avoid this?  I think it will be scary for users, even though gnuplot is really just saying that it is ignoring the following construct.



Rik <rik5>
Group administrator
Fri 19 Jun 2015 07:48:27 AM UTC, comment #10: 

I added the


set(h, 'edgecolor', 'r')
set(h, 'linewidth', 3)
set(h, 'linestyle', ':')
set(h, 'facecolor', 'y')


simply as an illustration that those plot elements are controllable now.  You may leave that off.

Yes, the line is covered up by the plot surface.  gnuplot doesn't apply hidden3d to what is called "pm3d".  The algorithm used is what is sometimes referred to as the "painters algorithm", in that it simply paints the surface elements depending on depth of the elements.  I've wanted to do a true hidden3d surface algorithm in gnuplot for years, but it is a big job and I haven't found the time.

There might be a way to make hidden3d behave correctly in simple cases.  (We did a similar sort of thing for hidden3d and images recently.)


Dan Sebald <sebald>
Thu 18 Jun 2015 06:09:23 AM UTC, comment #9: 


comment #6: The plot is better than what I get now,
but there are still two problems:
1. The color is different from fltk color. The
facecolor should be [.3 .5 .3], and the edgecolor should be
black and solid  and not red and dashed.
2. The line (t,t,t) is not seen

Avinoam Kalma <avinoam>
Group Member
Mon 15 Jun 2015 06:57:46 PM UTC, comment #8: 

Comment 6: Yes, I suppose that looks right.  Of course, bright yellow and dotted-red probably not one's first choice.

Comment 7: The caret appears to be pointing at "border".  I suppose that is something new as well.  It's a warning in the sense that gnuplot continues if it finds an option it has no knowledge of and isn't otherwise incomplete or conflicting.  It looks like border may have been added for this mode on 2014-04-02.  I just built a copy of the code from that date.  It seems gnuplot version scheme is to use, e.g., "5.0 patchlevel alpha", for prerelease.  If a user is using official releases only, I suppose that's no problem.  But if getting the copy from gnuplot's repository, the _gnuplot_version_() routine might be confused into thinking that is 5.0.  I'm not going to worry about that.  In any case, in the attached patch I've lumped the pm3d "border" option along with "dashtype" since the two appear to coincide with 5.0.

(file #34227)

Dan Sebald <sebald>
Mon 15 Jun 2015 04:48:50 AM UTC, comment #7: 

Running gnuplot 4.6.6, I get several errors,


octave:1> graphics_toolkit("gnuplot");
octave:2> figure();
octave:3>
octave:3> [x, y] = meshgrid (-2:.2:2);
octave:4> t = linspace (-2, 2, 10);
octave:5> z = (1+x.*y).*(x+y);
octave:6> h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);

gnuplot> set pm3d explicit at s hidden3d border hidden3d linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                         ^
         line 0: invalid pm3d option

octave:7> hold on

gnuplot> set pm3d explicit at s hidden3d border hidden3d linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                         ^
         line 0: invalid pm3d option

octave:8> plot3 (t, t, t)

gnuplot> set pm3d explicit at s hidden3d border hidden3d linetype 1 linecolor rgb "#000000" linewidth 0.500000  depthorder corners2color c3;
                                         ^
         line 0: invalid pm3d option


On the positive side, the plot appears to be correct.

Rik <rik5>
Group administrator
Sun 14 Jun 2015 10:10:12 PM UTC, comment #6: 

I can't test earlier versions of gnuplot, but with 5.0 and the patch applied to octave-3.8.2 (I'm not able to build later versions on MacOS Yosemite), I get the attached plot.

Is this what is expected?


Ben Abbott <bpabbott>
Group Member
Sun 14 Jun 2015 09:03:45 PM UTC, comment #5: 

BTW, I've used a gnuplot 5.0 feature in the patch if things don't work out quite right and you have a <5.0 version.

Dan Sebald <sebald>
Sun 14 Jun 2015 08:59:38 PM UTC, comment #4: 

I've attached a changeset fixing the surface color setting.  It also adds linestyle control for the lines of the surface.  Please give it a try.  Keep in mind there are some limitations with hidden 3d behavior.  The line in your example is not going to be properly segmented and displayed.  You may need to do that manually.  Here is some sample script for you to experiment with:


graphics_toolkit("gnuplot");
figure();

[x, y] = meshgrid (-2:.2:2);
t = linspace (-2, 2, 10);
z = (1+x.*y).*(x+y);
h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);
hold on
plot3 (t, t, t)

set(h, 'edgecolor', 'r')
set(h, 'linewidth', 3)
set(h, 'linestyle', ':')
set(h, 'facecolor', 'y')


(file #34218)

Dan Sebald <sebald>
Fri 30 Aug 2013 02:59:17 AM UTC, comment #3: 

This bug is still present on the development branch with gnuplot 4.6.2.  The FLTK toolkit, however, works just fine.

Rik <rik5>
Group administrator
Sun 06 Nov 2011 02:06:45 AM UTC, comment #2: 

A more accurate summary.

Ben Abbott <bpabbott>
Group Member
Sun 06 Nov 2011 02:05:21 AM UTC, comment #1: 

The third command has a problem.


z = (1+x.y).(x+y);
error: matrix cannot be indexed with .


I tried the commands below.


figure (1)
clf
[x, y] = meshgrid (-2:.2:2);
t = linspace (-2, 2, 10);
z = (1+x.*y).*(x+y);
plot3 (t, t, t)
hold on
h = surf (x, y, z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0]);
facecolor = get (h, "facecolor")
edgecolor = get (h, "edgecolor")


I've attached pdf's from ML and Octave.

(file #24310, file #24311)

Ben Abbott <bpabbott>
Group Member
Tue 11 Oct 2011 12:22:40 AM UTC, original submission:  

octave:1> [x,y] = meshgrid(-2:.2:2);
octave:2> t = linspace(-2,2,10);
octave:3> z = (1+x.*y).*(x+y);
octave:4> plot3(t,t,t)
octave:5> hold on
octave:6> surf(x,y,z, "FaceColor", [.3 .5 .3], "EdgeColor", [0 0 0])
octave:7> version
ans = 3.2.4
gnuplot -V
gnuplot 4.4 patchlevel 0

When the result was returned the FaceColor property had not been set to a single color, it was still the default color map. Also the line could not be seen superimposed on the side of the surface it was graphed with. It was only visible when the plot was oriented so that the line was in front of only whitespace. When the surface was plotted first, and then the line, the line could be seen in front of the surface as expected, but it could also be seen behind the surface where I would expect it to be hidden.

Peter Jeffris <jeffris>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #36579:  changeset.patch added by bpabbott (1KiB - application/octet-stream - consistent dashtypes across gnuplot terminals)
file #36502:  changeset.patch added by bpabbott (22KiB - application/octet-stream - Modified by bpa to apply to tip df5922f77193)
file #34329:  octave-gnuplot_surf_facecolor-djs2015jun26.patch added by sebald (22KiB - application/octet-stream - New strategy using linetype rather than linestyle and restructuring slightly)
file #34264:  surf_gnuplot.png added by rik5 (117KiB - image/png)
file #34265:  surf_fltk.png added by rik5 (26KiB - image/png)
file #24310:  matlab.pdf added by bpabbott (78KiB - application/pdf)
file #24311:  gnuplot.pdf added by bpabbott (14KiB - application/pdf)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Updated the item)
  • -email is unavailable- added by jeffris (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 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-06 rik5 Open/ClosedOpen Closed
    2016-03-09 bpabbott Attached File- Added changeset.patch, #36579
    2016-02-29 rik5 Summarysurf() with gnuplot does not handle FaceColor correctly linestyle not always used for 3D plots (gnuplot)
    2016-02-29 bpabbott Attached File- Added changeset.patch, #36502
    2015-06-27 sebald Attached File- Added octave-gnuplot_surf_facecolor-djs2015jun26.patch, #34329
    2015-06-24 sebald Attached File- Added octave-gnuplot_surf_facecolor-djs2015jun24.patch, #34308
    2015-06-23 sebald Attached File- Added octave-gnuplot_surf_facecolor-djs2015jun23.patch, #34301
    2015-06-19 rik5 Attached File- Added surf_gnuplot.png, #34264
        Attached File- Added surf_fltk.png, #34265
    2015-06-15 sebald Attached File- Added octave-gnuplot_surf_facecolor-djs2015jun15.patch, #34227
    2015-06-14 bpabbott Attached File- Added gnuplot-5.0-x11 on MacOSX with patch applied to stable.png, #34219
    2015-06-14 sebald Attached File- Added octave-gnuplot_surf_facecolor-djs2015jun14.patch, #34218
    2015-03-15 rik5 Summarysurf() does not handle FaceColor correctly surf() with gnuplot does not handle FaceColor correctly
    2015-03-14 mtmiller Release3.2.4 dev
        Operating SystemGNU/Linux Any
    2014-12-26 rik5 Dependencies- bugs #43890 is dependent
    2011-11-06 bpabbott SummaryPlot Bugs surf() does not handle FaceColor correctly
    2011-11-06 bpabbott Attached File- Added matlab.pdf, #24310
        Attached File- Added gnuplot.pdf, #24311
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code