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.
|
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)
|
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:')"
|
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)
|
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?
|
Tue 07 Jul 2015 06:18:37 PM UTC, comment #20:
This changeset is ready for testing.
|
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.
|
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.
|
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)
|
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.
|
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.
|
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)
|
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?
|
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)
|
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)
|
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.)
|
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
|
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)
|
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.
|
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)
|
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.
|
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)
|
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.
|
Sun 06 Nov 2011 02:06:45 AM UTC, comment #2:
A more accurate summary.
|
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)
|
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.
|