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

 
 

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

Submitted by:  Peter Jeffris <jeffris>
Submitted on:  Tue 11 Oct 2011 12:22:40 AM UTC  
 
Category: Plotting with gnuplotSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: PeterOpen/Closed: Closed
Release: devOperating System: Any

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 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>
Project 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".

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>
Project 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:

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.

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

Rik <rik5>
Project 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>
Project 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>
Project 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 xy with pm3d, xy 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.

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

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:

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>
Project 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

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.

(file #34264, file #34265)

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

I added the

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>
Project 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,

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

Rik <rik5>
Project 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?

(file #34219)

Ben Abbott <bpabbott>
Project 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:

(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>
Project Administrator
Sun 06 Nov 2011 02:06:45 AM UTC, comment #2:

A more accurate summary.

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

The third command has a problem.

I tried the commands below.

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

(file #24310, file #24311)

Ben Abbott <bpabbott>
Project 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 File(s):
   
   
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
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by sebald (Updated the item)
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by bpabbott (Updated the item)
  • -unavailable- added by jeffris (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 20 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 06 Sep 2016 12:16:11 AM UTCrik5Open/ClosedOpen=>Closed
    Wed 09 Mar 2016 12:57:05 PM UTCbpabbottAttached File-=>Added changeset.patch, #36579
    Mon 29 Feb 2016 03:36:26 AM UTCrik5Summarysurf() with gnuplot does not handle FaceColor correctly=>linestyle not always used for 3D plots (gnuplot)
    Mon 29 Feb 2016 02:07:49 AM UTCbpabbottAttached File-=>Added changeset.patch, #36502
    Sat 27 Jun 2015 04:14:31 AM UTCsebaldAttached File-=>Added octave-gnuplot_surf_facecolor-djs2015jun26.patch, #34329
    Wed 24 Jun 2015 05:53:25 PM UTCsebaldAttached File-=>Added octave-gnuplot_surf_facecolor-djs2015jun24.patch, #34308
    Tue 23 Jun 2015 09:22:47 PM UTCsebaldAttached File-=>Added octave-gnuplot_surf_facecolor-djs2015jun23.patch, #34301
    Fri 19 Jun 2015 04:11:27 PM UTCrik5Attached File-=>Added surf_gnuplot.png, #34264
      Attached File-=>Added surf_fltk.png, #34265
    Mon 15 Jun 2015 06:57:46 PM UTCsebaldAttached File-=>Added octave-gnuplot_surf_facecolor-djs2015jun15.patch, #34227
    Sun 14 Jun 2015 10:10:12 PM UTCbpabbottAttached File-=>Added gnuplot-5.0-x11 on MacOSX with patch applied to stable.png, #34219
    Sun 14 Jun 2015 08:59:38 PM UTCsebaldAttached File-=>Added octave-gnuplot_surf_facecolor-djs2015jun14.patch, #34218
    Sun 15 Mar 2015 03:03:47 PM UTCrik5Summarysurf() does not handle FaceColor correctly=>surf() with gnuplot does not handle FaceColor correctly
    Sat 14 Mar 2015 09:14:11 PM UTCmtmillerRelease3.2.4=>dev
      Operating SystemGNU/Linux=>Any
    Fri 26 Dec 2014 03:20:56 PM UTCrik5Dependencies-=>bugs #43890 is dependent
    Sun 06 Nov 2011 02:06:45 AM UTCbpabbottSummaryPlot Bugs=>surf() does not handle FaceColor correctly
    Sun 06 Nov 2011 02:05:21 AM UTCbpabbottAttached File-=>Added matlab.pdf, #24310
      Attached File-=>Added gnuplot.pdf, #24311
      StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1