Fri 18 Nov 2016 05:45:28 AM UTC, comment #19:
This has been fixed somewhere in the last five years. I did 'demo trisurf' with 4.2.0.
|
Thu 06 Jun 2013 06:34:49 AM UTC, comment #18:
I don't know when I'll have time to get back to this, so I'm removing myself as assignee.
|
Wed 28 Dec 2011 09:30:41 PM UTC, comment #17:
Update: After some more testing, I've conclude the last several changeset won't function properly. They use gnuplot commands like
The result is that the last splot erases the prior results. I had used this approach to allow different line styles to be used for draw the mesh associated the trisurf patch object.
For now, I don't see how gnuplot can render different meshed surfaces with differing lines used for the edges.
If I don't come up with something in the next few days, i plan to close this report and open a new one with a bit more detail on the problem.
|
Tue 27 Dec 2011 07:56:43 PM UTC, comment #16:
I've attached a fifth changeset. This one has not yet been pushed.
To test, try
The demos with facecolor == flat should have a visible mesh.
(file #24683)
|
Mon 26 Dec 2011 12:36:35 AM UTC, comment #15:
Trimesh renders the mesh, but trisurf does not (neither lines nor markers).
One approach which renders lines is to make the change below to the gnuplot plot-stream.
Unfortunately, this isn't a general solution, but I thought it best to document it here.
|
Sun 25 Dec 2011 07:45:55 PM UTC, comment #14:
I did some more testing of the edgecolor. Apparently, the line associated with gnuplot's 3D patches works differently.
The result is a blackline drawn around the visible perimeter of the image.
I'm not sure how this can easily be fixed.
|
Sun 25 Dec 2011 07:03:11 PM UTC, comment #13:
I've attached a fourth attempt, and pushed it.
http://hg.savannah.gnu.org/hgweb/octave/rev/5be545210fe3
This one fixes the rendered facecolors and color limits.
I ran the plot demos for both gnuplot and fltk, and didn't notice any regressions.
Note: I noticed that when using gnuplot, the edgecolor isn't working correctly. I'll look at that next. I'm not sure if a fix for the edgecolor belongs in stable or default. If anyone has an opinion, let me know.
(file #24665)
|
Fri 23 Dec 2011 09:55:01 PM UTC, comment #12:
I noticed that the trisurf implementation set the facevertexcdata directly. This resulted in an empty cdata property and prevented the patch color from being taken into account when climmode == auto.
The third changeset I'm attaching switches to using the {x,y,z,c}data inputs when calling patch(). This fixed the clim problem but also reveals that the fltk backend doesn't handle patches correctly.
I've added a new demo (first one). Typing "demo trisurf 1" produces the same result as does ML. The fltk backend result is messed up.
(file #24657)
|
Fri 23 Dec 2011 08:32:58 PM UTC, comment #11:
Re-titling bug report to remaining open issue.
|
Thu 22 Dec 2011 06:46:51 PM UTC, comment #10:
Rik,
I had noticed a slight difference as well. I'll make a note to myself to look into this a bit deeper next week ... I have to week off from the normal grind :-)
I'll have to study the ML docs to see what the best approximation is for the gnuplot backend.
For reference, I've attached the results I get using ML R2011b.
(file #24651)
|
Thu 22 Dec 2011 06:17:45 PM UTC, comment #9:
Thanks Ben!
All four demos run in gnuplot now for me as well using tip (14095:595ee644fa6f). I'm writing now only to report that there is a slight difference in the resulting plots. For the FLTK plot both the mesh and the surface are drawn. For the gnuplot version it appears that perhaps only the surface is drawn.
To get an idea of what I mean, try "demo ("surf", 1)" which is the 2-D version. It shows both mesh and surface for either toolkit.
This may be another limitation of gnuplot. I tried increasing the edgewidth to 3 and the edgecolor property to [1 0 1] (hot pink) and I can see that some of the mesh is being drawn.
|
Thu 22 Dec 2011 04:07:32 PM UTC, comment #8:
all four example are now fine.
|
Thu 22 Dec 2011 03:41:35 PM UTC, comment #7:
Second attempt is attached.
(file #24650)
|
Thu 22 Dec 2011 03:29:25 PM UTC, comment #6:
first two work. but the third example fails:
/usr/local/share/octave/3.5.90+/m/plot/trisurf.m example 3:
clf
x = rand (100, 1);
y = rand (100, 1);
z = x.^2 + y.^2;
tri = delaunay (x, y);
trisurf (tri, x, y, z, "facecolor", "interp");
error: _go_draw_axes_: subscript indices must be either positive integers or logicals
error: called from:
error: /pub/hg/octave_build/../octave/scripts/plot/private/__go_draw_axes__.m at line 759, column 37
error: /pub/hg/octave_build/../octave/scripts/plot/private/__go_draw_figure__.m at line 167, column 19
error: /pub/hg/octave_build/../octave/scripts/plot/__gnuplot_drawnow__.m at line 86, column 5
error: input: reading user-input failed!
error: /pub/hg/octave_build/../octave/scripts/testfun/demo.m at line 119, column 7
|
Thu 22 Dec 2011 03:17:04 PM UTC, comment #5:
I had improperly linked qhull in my earlier build. The result was no error, and no plot. I've corrected that and now see the error.
Proposed changeset is attached.
(file #24649)
|
Thu 22 Dec 2011 01:47:54 PM UTC, comment #4:
both. With gnuplot, I get the error and no plot
octave:1> demo /usr/local/share/octave/3.5.90+/m/plot/trisurf.m
/usr/local/share/octave/3.5.90+/m/plot/trisurf.m example 1:
clf
old_state = rand ("state");
restore_state = onCleanup (@() rand ("state", old_state));
rand ("state", 10);
N = 10;
x = 3 - 6 * rand (N, N);
y = 3 - 6 * rand (N, N);
z = peaks (x, y);
tri = delaunay (x(:), y(:));
trisurf (tri, x(:), y(:), z(:));
error: _go_draw_axes_: operator *: nonconformant arguments (op1 is 0x0, op2 is 3x1)
error: called from:
error: /usr/local/share/octave/3.5.90+/m/plot/private/__go_draw_axes__.m at line 701, column 30
error: /usr/local/share/octave/3.5.90+/m/plot/private/__go_draw_figure__.m at line 167, column 19
error: /usr/local/share/octave/3.5.90+/m/plot/__gnuplot_drawnow__.m at line 86, column 5
error: input: reading user-input failed!
error: /usr/local/share/octave/3.5.90+/m/testfun/demo.m at line 119, column 7
The error arises from trisurf call
|
Thu 22 Dec 2011 01:20:54 PM UTC, comment #3:
Marco, by "fail" do you mean you get the error, or that you don't get the graphic intended?
|
Thu 22 Dec 2011 10:48:11 AM UTC, comment #2:
it fails on gnuplot and pass on fltk on cygwin
|
Thu 22 Dec 2011 12:13:17 AM UTC, comment #1:
I'm not seeing a crash with the stable branch.
|
Wed 21 Dec 2011 11:29:13 AM UTC, original submission:
all the trisurf demos fail with
----------------------------------------------------------------
error: _go_draw_axes_: operator *: nonconformant arguments (op1 is 0x0, op2 is 3x1)
error: called from:
error: /usr/local/share/octave/3.5.90+/m/plot/private/__go_draw_axes__.m at line 701, column 30
error: /usr/local/share/octave/3.5.90+/m/plot/private/__go_draw_figure__.m at line 167, column 19
error: /usr/local/share/octave/3.5.90+/m/plot/__gnuplot_drawnow__.m at line 86, column 5
---------------------------------------------------------------
a more general trisurf bug, or side effect of something else ?
|