[Octave-bug-tracker] [bug #42561] gnuplot colors incorrect for 'demo trimesh'

[Dan Sebald]

Follow-up Comment #27, bug #42561 (project octave):

OK, your meshtst.var example is great.  I substituted -x and -y for the input
to mesh() and it suggests that the order relationship of amplitude of the
position variables as opposed to the order of the position variables is what's
used.  I.e.,


load meshtst.var
close all
graphics_toolkit fltk
figure ("colormap", [1 0 0; 0 1 0; 0 0 1]);
hm = mesh (-x, -y, z, cdata)
h2 = copyobj (1)
graphics_toolkit (h2, "gnuplot")
figure (1)
title ("FLTK");
figure (2)
title ("gnuplot");


That is, in this case |-1| < |-2| so it is the -1 position value that is used.
 Also, it's still not 100% accurate.  Is it Euclidean distance, x^2 + y^2,
that is used for comparison?   Or some other distance like sup-norm, |x| +
|y|?

Why is it distance from the origin (regardless of the quadrant)?  My guess
would be that Matlab thought such a definition would look good in the cases of
plotting symmetric 2D functions, such as the sombrero and so many other quick
yet interesting plots.  Otherwise the colors of the mesh/surface wouldn't be
symmetric while the function is.  Of course, plotting a function symmetric
about somewhere other than the origin would come out with nonsymmetric
colors.

gnuplot toolkit is using lines with the "palette" setting for these color mesh
plots.  There is no means of controlling the behavior of that.  However, the
interesting thing is that there appears to be a new plot element for *every*
line in the mesh.  (No wonder the gnuplot plots are somewhat sluggish to
initially draw.)  That means I might be able to specify an RGB linecolor for
individual lines rather than indicating to simply use the palette (i.e.,
colormap).  That opens the possibility for implementing this color blending
algorithm in __gnuplot_draw_axes__.m and bypassing the palette altogether for
mesh.

I'll look at this in the next few days.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42561>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/