[Octave-bug-tracker] [bug #48427] legend objects in gnuplot

[Dan Sebald]

Follow-up Comment #12, bug #48427 (project octave):

> I indended 'case "patch"' by an extra space
> (http://hg.savannah.gnu.org/hgweb/octave/rev/43646269998d).

OK, thanks.


> The color of the pyramid changes dramatically after calling legend which I
> don't think was intended. This is with gnuplot 5.0.1 which I think is a
> pretty buggy version, but still. I'd rather leave that alone.

I lean more toward just placing the patch in the legend because in some
instances the user could specify a color triad and get something close to what
they want.  This is useful for images, for fairly smooth surfaces, etc.

The result you are seeing is not a bug, but a limitation of gnuplot, one that
I've wanted to address for a decade or more. It's that gnuplot does not have a
true hidden surface algorithm. It has a hidden line algorithm, but that is
slightly more straightforward.  However, it really isn't the nature of the
problem that is difficult; it is all of the underlying book-keeping that goes
with breaking up potentially intersecting finite elements into sub-pieces,
discarding this piece, reordering that piece, etc.

Instead, many years ago someone implemented what is known as the painter's
algorithm in which one takes, say, the average depth value of the element and
then does a simple sort on that list, drawing the elements in succession. It
is quite common for surfaces to overlap incorrectly with the painters
algorithm, especial with intersecting surfaces. If one makes the number of
pieces small enough, generally this overlap is not noticeable. But in the case
of this pyramid, there are only four elements, so any sort order or overlap
flaw becomes very noticeable. As with any limited solution, designers become
content that it is good enough, so the idea of writing a correct solution
becomes a lower priority and less willingness to modify.

What makes the pyramid tricky is that the four triangles all share that common
point, so depending upon the type of depth sort, the order can get mixed up on
rotation. Introducing the legend probably adds another piece to the sort list
and that might cause some elements to be rearrange. But, even without the
legend, I think just rotating the surface reveals the same issue. Anyway, as
soon as I saw this pyramid demo months or years ago, I knew there would be a
problem.  If I can find some other way of fixing this with some type of
gnuplot configuration, I'll create a separate patch.


> I changed create_spacingspec to return an empty string and it seems to work
> fine for
>
> demo legend
>
> But maybe you can check that more closely.

I tried this too and it works. However, I'm going to try something slightly
more extensive because changing that font size also changes the size of the
sample, i.e., gnuplot's automatic layout mode.  I don't think that is the way
Octave intends to work--changing the font size doesn't change the sample size.
 Let me try to make that whole legend layout a little more non-automatic.  I
sent a post to the gnuplot maintainers list about some inconsistencies in
scaling/units, so I'm waiting on that.


    _______________________________________________________

Reply to this item at:

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

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