gnuplot-beta

Is "border" in pm3d redundant?

[Daniel J S. <dan...@ie...>]

I was working on an application for which there's to be color surface 
and mesh lines.  I began down the route of "border" feature for pm3d, 
which is fairly new.  But after a while of not getting what I'd hoped 
for in hidden3d mode, I began to wonder if pm3d/border is redundant 
because gnuplot almost has such capability without the "border" feature. 
  Having

splot x+y with pm3d border <line characteristics>

is sort of re-implementing

splot x+y with pm3d, x+y with lines <line characteristics>

In the long run we'd like some type of surface color control and true 
hidden3d surface removal.  I know pm3d and hidden3d don't combine just 
right, but that doesn't mean the syntax can't trend in a desired direction.

The general principle is that the user may want to use the same function 
or data set for multiple plot elements, e.g.,

splot "foo" with lines <line chars> [and] surfels <face chars>

(or "polygons", "faces", whatever).  However, the "and" concept kind of 
exists already with the special "-" filename:

splot "foo" with lines <line chars>,
       "-" with surfels <face chars>

That is essentially saying "and" because there is no new function/file 
specification.

So, I'm wondering if things are branching here a bit with regard to 
pm3d/border and in the long run what the best approach is.  As I said, 
after some use, I have second thoughts of adding more plot elements via 
some existing element's option.  I'd rather use a syntax that seems more 
in line with the eventual concept.

Dan

Re: Is "border" in pm3d redundant?

[Ethan A M. <sf...@us...>]

On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
> I was working on an application for which there's to be color surface 
> and mesh lines.  I began down the route of "border" feature for pm3d, 
> which is fairly new.  But after a while of not getting what I'd hoped 
> for in hidden3d mode, I began to wonder if pm3d/border is redundant 
> because gnuplot almost has such capability without the "border" feature. 
>   Having
> 
> splot x+y with pm3d border <line characteristics>
> 
> is sort of re-implementing
> 
> splot x+y with pm3d, x+y with lines <line characteristics>
> 
> In the long run we'd like some type of surface color control and true 
> hidden3d surface removal.  I know pm3d and hidden3d don't combine just 
> right, but that doesn't mean the syntax can't trend in a desired direction.
> 
> The general principle is that the user may want to use the same function 
> or data set for multiple plot elements, e.g.,
> 
> splot "foo" with lines <line chars> [and] surfels <face chars>
> 
> (or "polygons", "faces", whatever).  However, the "and" concept kind of 
> exists already with the special "-" filename:
> 
> splot "foo" with lines <line chars>,
>        "-" with surfels <face chars>
> 
> That is essentially saying "and" because there is no new function/file 
> specification.

I don't understand. Maybe you mean "" rather than "-"?

I really don't see any need for an "and" syntax.

	Ethan


> 
> So, I'm wondering if things are branching here a bit with regard to 
> pm3d/border and in the long run what the best approach is.  As I said, 
> after some use, I have second thoughts of adding more plot elements via 
> some existing element's option.  I'd rather use a syntax that seems more 
> in line with the eventual concept.
> 
> Dan

Re: Is "border" in pm3d redundant?

[Daniel J S. <dan...@ie...>]

On 06/25/2015 01:51 PM, Ethan A Merritt wrote:
> On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
>
>>  I was working on an application for which there's to be color surface
>
>>  and mesh lines. I began down the route of "border" feature for pm3d,
>
>>  which is fairly new. But after a while of not getting what I'd hoped
>
>>  for in hidden3d mode, I began to wonder if pm3d/border is redundant
>
>>  because gnuplot almost has such capability without the "border" feature.
>
>>  Having
>
>>
>
>>  splot x+y with pm3d border <line characteristics>
>
>>
>
>>  is sort of re-implementing
>
>>
>
>>  splot x+y with pm3d, x+y with lines <line characteristics>
>
>>
>
>>  In the long run we'd like some type of surface color control and true
>
>>  hidden3d surface removal. I know pm3d and hidden3d don't combine just
>
>>  right, but that doesn't mean the syntax can't trend in a desired
> direction.
>
>>
>
>>  The general principle is that the user may want to use the same function
>
>>  or data set for multiple plot elements, e.g.,
>
>>
>
>>  splot "foo" with lines <line chars> [and] surfels <face chars>
>
>>
>
>>  (or "polygons", "faces", whatever). However, the "and" concept kind of
>
>>  exists already with the special "-" filename:
>
>>
>
>>  splot "foo" with lines <line chars>,
>
>>  "-" with surfels <face chars>
>
>>
>
>>  That is essentially saying "and" because there is no new function/file
>
>>  specification.
>
> I don't understand. Maybe you mean "" rather than "-"?

Yes, something like that.  I was just typing from memory, recalling that 
there is some syntax that utilizes the previous data.


> I really don't see any need for an "and" syntax.

The title of the thread is "Is border in pm3d redundant?"  The question 
is whether "border" is needed since what it achieves (which is plot this 
"and" that using the same data file) already essentially exists in a 
more robust and conceptually consistent manner.

Is there something beneficial to "border" beyond the syntax that already 
existed?

Dan

Re: Is "border" in pm3d redundant?

[Ethan A M. <sf...@us...>]

On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
> On 06/25/2015 01:51 PM, Ethan A Merritt wrote:
> > On Thursday, 25 June, 2015 12:54:55 Daniel J Sebald wrote:
> >
> >>  I was working on an application for which there's to be color surface
> >
> >>  and mesh lines. I began down the route of "border" feature for pm3d,
> >
> >>  which is fairly new. But after a while of not getting what I'd hoped
> >
> >>  for in hidden3d mode, I began to wonder if pm3d/border is redundant
> >
> >>  because gnuplot almost has such capability without the "border" feature.
> >
> >>  Having
> >
> >>
> >
> >>  splot x+y with pm3d border <line characteristics>
> >
> >>
> >
> >>  is sort of re-implementing
> >
> >>
> >
> >>  splot x+y with pm3d, x+y with lines <line characteristics>
> >
> >>
> >
> >>  In the long run we'd like some type of surface color control and true
> >
> >>  hidden3d surface removal. I know pm3d and hidden3d don't combine just
> >
> >>  right, but that doesn't mean the syntax can't trend in a desired
> > direction.
> >
> >>
> >
> >>  The general principle is that the user may want to use the same function
> >
> >>  or data set for multiple plot elements, e.g.,
> >
> >>
> >
> >>  splot "foo" with lines <line chars> [and] surfels <face chars>
> >
> >>
> >
> >>  (or "polygons", "faces", whatever). However, the "and" concept kind of
> >
> >>  exists already with the special "-" filename:
> >
> >>
> >
> >>  splot "foo" with lines <line chars>,
> >
> >>  "-" with surfels <face chars>
> >
> >>
> >
> >>  That is essentially saying "and" because there is no new function/file
> >
> >>  specification.
> >
> > I don't understand. Maybe you mean "" rather than "-"?
> 
> Yes, something like that.  I was just typing from memory, recalling that 
> there is some syntax that utilizes the previous data.
> 
> 
> > I really don't see any need for an "and" syntax.
> 
> The title of the thread is "Is border in pm3d redundant?"  The question 
> is whether "border" is needed since what it achieves (which is plot this 
> "and" that using the same data file) already essentially exists in a 
> more robust and conceptually consistent manner.
> 
> Is there something beneficial to "border" beyond the syntax that already 
> existed?

I don't know of another way to get the equivalent of 

  set pm3d hidden3d border lc "black"
  splot x*y with pm3d

If you try to draw the lines in a separate plot clause, the
hidden3d effect is lost.

	Ethan


> 
> Dan
> 
> ------------------------------------------------------------------------------
> Monitor 25 network devices or servers for free with OpManager!
> OpManager is web-based network management software that monitors 
> network devices and physical & virtual servers, alerts via email & sms 
> for fault. Monitor 25 devices for free with no restriction. Download now
> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Is "border" in pm3d redundant?

[Daniel J S. <dan...@ie...>]

On 06/25/2015 02:22 PM, Ethan A Merritt wrote:
> On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
[snip]
>>  Is there something beneficial to "border" beyond the syntax that already
>
>>  existed?
>
> I don't know of another way to get the equivalent of
>
> set pm3d hidden3d border lc "black"
>
> splot x*y with pm3d
>
> If you try to draw the lines in a separate plot clause, the
>
> hidden3d effect is lost.

How about?

set hidden3d front
set samples 100,10
set isosamples 100,10
splot x*y with pm3d, x*y with lines lc "black"

That seems pretty close to the same plot, at least conceptually.  There 
may be some subtle difference.  Generally, it may not be true that pm3d 
works with hidden3d, but when the two data sets are the same surface it 
is fairly accurate behavior.

Dan

Re: Is "border" in pm3d redundant?

[Ethan A M. <sf...@us...>]

On Thursday, 25 June, 2015 15:03:14 Daniel J Sebald wrote:
> On 06/25/2015 02:22 PM, Ethan A Merritt wrote:
> > On Thursday, 25 June, 2015 14:05:02 Daniel J Sebald wrote:
> [snip]
> >>  Is there something beneficial to "border" beyond the syntax that already
> >
> >>  existed?
> >
> > I don't know of another way to get the equivalent of
> >
> > set pm3d hidden3d border lc "black"
> >
> > splot x*y with pm3d
> >
> > If you try to draw the lines in a separate plot clause, the
> >
> > hidden3d effect is lost.
> 
> How about?
> 
> set hidden3d front
> set samples 100,10
> set isosamples 100,10
> splot x*y with pm3d, x*y with lines lc "black"
> 
> That seems pretty close to the same plot, at least conceptually.  There 
> may be some subtle difference. 

Right. That is one of the work-arounds that can be made to handle
a common case, as in the "hidden2.dem" example.  But it doesn't
extend to the general case.

Anyhow, if there are two ways to get the same output picture - so what?
I advocate for the Perl philosophy:
  "There's more than one way to do it!"
as opposed to the Python countervailing view:
  "there should be one — and preferably only one - obvious way to do it"

	Ethan