gnuplot-beta — Developers and beta testers of new gnuplot code

Re: White space balance has changed

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

On Wednesday, 08 June, 2016 11:07:28 Daniel J Sebald wrote:
> I've been stepping through the demos, and my general observation from 
> what I remember is that there is now much less white space around plots. 
>   The behavior is the same in two different terminals (x11 and qt). 
> I've gone back to about -D2016-05-25 in the repository to see if this is 
> a current inadvertent change.  It's the same as current development version.

The default margins for "set view map; splot ..." were changed to be
more like those for an equivalent 2D plot.  So that category of plot
is expected to have less white space around it than in old gnuplot
versions.


> Has anyone else noticed this?  Perhaps it was intentional, and in some 
> sense I don't mind it because it makes the plots use more of the 
> available window screen.  I mean, typically when I create a plot for a 
> publication I will reduce the whitespace to minimal because word 
> processors can always add it back in.  That can be done changing the 
> margins or post-gnuplot with some cropping tool specific to, say, eps or 
> something.
> 
> However, as far as the demos, the plots don't feel as though they have a 
> good white space balance for several plots.  Here are some notable ones:

 
> fillcrvs.dem (7) world.dat plotted with filledcurves
> multiplt.dem (1)

I have no explanation for any changes seen in these

> [The above two illustrate how plot are is slightly skewed to the left]
> heatmaps.dem (1) (2) (3) (4)

These are set view map + splot, so changes are expected

> piecewise.dem (1) Piecewise function sampling
> matrix_index.dem (1) Data file contains labeled ascii matrices 
> [annotation off screen]

These demos did not exist prior to version 5, so I'm not sure what
you are comparing to.  The output looks normal when tested here.

	Ethan

White space balance has changed

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

I've been stepping through the demos, and my general observation from 
what I remember is that there is now much less white space around plots. 
  The behavior is the same in two different terminals (x11 and qt). 
I've gone back to about -D2016-05-25 in the repository to see if this is 
a current inadvertent change.  It's the same as current development version.

Has anyone else noticed this?  Perhaps it was intentional, and in some 
sense I don't mind it because it makes the plots use more of the 
available window screen.  I mean, typically when I create a plot for a 
publication I will reduce the whitespace to minimal because word 
processors can always add it back in.  That can be done changing the 
margins or post-gnuplot with some cropping tool specific to, say, eps or 
something.

However, as far as the demos, the plots don't feel as though they have a 
good white space balance for several plots.  Here are some notable ones:

fillcrvs.dem (7) world.dat plotted with filledcurves
multiplt.dem (1)
[The above two illustrate how plot are is slightly skewed to the left]
heatmaps.dem (1) (2) (3) (4)
piecewise.dem (1) Piecewise function sampling
matrix_index.dem (1) Data file contains labeled ascii matrices 
[annotation off screen]

Dan

RE: X11 compilation errors gnuplot 5

[Bastian M. <bma...@we...>]

> -----Original Message-----
> From: rytis [mailto:bu...@gm...]
> Sent: Mittwoch, 1. Juni 2016 10:28
> To: gnu...@li...
> Subject: X11 compilation errors gnuplot 5
> 
> Hello
> At some point during the compilation of Gnuplot 5, the compilation fails.
> 
> In this case, making the target called binonly that is located in
gnuplot/src,
> the -lX11 is missing (although it is checked for successfully in
configuration). I
> managed to fix this by adding the -lX11 flag at the end. What am I missing
> here?

This is a known bug - although I do not seem to find the relevant bug
tracker 
item just now.  The wxGTK configuration script fails to include the X11
library 
although it is required. 

Work-around is to prepend   TERMLIBS="-lX11"  to your ./configure call.

   Bastian

> 
> /usr/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol
> 'XInitThreads'
> //usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing
> from command line
> collect2: error: ld returned 1 exit status
> Makefile:787: recipe for target 'gnuplot' failed
> 
> Here is my configuration:
> ./configure --with-readline=gnu --with-qt --with-pdf --with-linux-vga
--with-
> ggi --with-gpic --with-mif --with-tutorial --with-cwdrc --with-kpsexpand
--
> with-lua
> 

X11 compilation errors gnuplot 5

[rytis <bu...@gm...>]

Hello
At some point during the compilation of Gnuplot 5, the compilation fails.

In this case, making the target called binonly that is located in
gnuplot/src, the -lX11 is missing (although it is checked for successfully
in configuration). I managed to fix this by adding the -lX11 flag at the
end. What am I missing here?

/usr/bin/ld: wxterminal/wxt_gui.o: undefined reference to symbol
'XInitThreads'
//usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status
Makefile:787: recipe for target 'gnuplot' failed

Here is my configuration: 
./configure --with-readline=gnu --with-qt --with-pdf --with-linux-vga
--with-ggi --with-gpic --with-mif --with-tutorial --with-cwdrc
--with-kpsexpand --with-lua



--
View this message in context: http://gnuplot.10905.n7.nabble.com/X11-compilation-errors-gnuplot-5-tp20132.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: octave w/ gnuplot backend produces bad pdf

[sfeam <sf...@us...>]

On Tuesday, 31 May 2016 03:11:44 PM sfeam wrote:
> On Tuesday, 31 May 2016 03:03:51 PM Dmitri A. Sergatskov wrote:
> > The following octave scrip produces a bad pdf
> > (similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
> > 
> > graphics_toolkit ("gnuplot")
> > x=linspace(-1,1,11);
> > y=0;
> > z=x;
> > mesh(x,y,z);
> > colormap([0,0,0]);
> > print("bad_pdf.pdf", "-dpdfcairo")
> > 
> > ====
> > 
> > A gnuplot script tat demonstrates the problem is attached (it contains
> > binary data).
> > 
> > Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> > would not.
> > 
> > I suspect the problem with octave's
> > colormap([0,0,0])
> > command here.
> > But I also think that gnuplot should not produce bad pdf.
> 
> I have not yet looked in detail, but my first thought is that the gnuplot command
> 	set palette ... maxcolors 1
> is a nonsense command.   A palette with only one color is no palette at all.

....and it's never going to work because of code like this:

   color.c:152    gray = (double) i / (sm_palette.colors - 1);    /* rescale to [0;1] */

and the equivalent is hard-wired into the PostScript palette code:

   /pm3dround {maxcolors 0 gt {dup 1 ge
        {pop 1} {maxcolors mul floor maxcolors 1 sub div} ifelse} if} def

So no.  maxcolors = 1 is not a legal value.

	Ethan

Re: octave w/ gnuplot backend produces bad pdf

[sfeam <sf...@us...>]

On Tuesday, 31 May 2016 03:03:51 PM Dmitri A. Sergatskov wrote:
> The following octave scrip produces a bad pdf
> (similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
> 
> graphics_toolkit ("gnuplot")
> x=linspace(-1,1,11);
> y=0;
> z=x;
> mesh(x,y,z);
> colormap([0,0,0]);
> print("bad_pdf.pdf", "-dpdfcairo")
> 
> ====
> 
> A gnuplot script tat demonstrates the problem is attached (it contains
> binary data).
> 
> Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> would not.
> 
> I suspect the problem with octave's
> colormap([0,0,0])
> command here.
> But I also think that gnuplot should not produce bad pdf.

I have not yet looked in detail, but my first thought is that the gnuplot command
	set palette ... maxcolors 1
is a nonsense command.   A palette with only one color is no palette at all.

I could understand a general case script that sometimes reduced to a
degenerate palette for which the endpoint colors were the same. 
This would correspond to gnuplot commands
      set palette defined (0 "black", 1 "black")
But in this case I expect the "maxcolors" parameter would still be 
0 (continuous interpolation) or 256 or whatever. 

	Ethan

Re: octave w/ gnuplot backend produces bad pdf

[Dmitri A. S. <das...@gm...>]

On Tue, May 31, 2016 at 4:35 PM, Daniel J Sebald <dan...@ie...>
wrote:

>
> So, it appears that there is either a Cairo bug or something is wrong in
> gnuplot (probably colorbar) when the number of color levels is 1.
>
>
​If you change colormap command to
​colormap([0,0,0;0,0,0])
it would work fine. But it is still one color level, isn't it?



> Dan
>
>
>
​Dmitri.
-- 
​

Re: octave w/ gnuplot backend produces bad pdf

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

My observations after modifying some lines of your .gp file:

1) The pngcairo terminal appears to work with your example.  I see a 
black line for all segments and the colorbox is all black.  This is how 
it appears in the PNG file and Qt terminal.

2) The attached modification "fixes" the pdfcairo view problems.  What I 
did was add more levels to the colorbox so that grey and white are 
visible.  I then see one segment of the line in black and another 
segment of the line in white.  This is how it appears in the PDF file 
and Qt terminal.

So, it appears that there is either a Cairo bug or something is wrong in 
gnuplot (probably colorbar) when the number of color levels is 1.

Dan


On 05/31/2016 03:03 PM, Dmitri A. Sergatskov wrote:
> The following octave scrip produces a bad pdf
> (similar to one in https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )
>
> graphics_toolkit ("gnuplot")
> x=linspace(-1,1,11);
> y=0;
> z=x;
> mesh(x,y,z);
> colormap([0,0,0]);
> print("bad_pdf.pdf", "-dpdfcairo")
>
> ====
>
> A gnuplot script tat demonstrates the problem is attached (it contains
> binary data).
>
> Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
> would not.
>
> I suspect the problem with octave's
> colormap([0,0,0])
> command here.
> But I also think that gnuplot should not produce bad pdf.
>
> Dmitri.
> --
>
>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

octave w/ gnuplot backend produces bad pdf

[Dmitri A. S. <das...@gm...>]

The following octave scrip produces a bad pdf
(similar to one in  https://bugzilla.redhat.com/show_bug.cgi?id=1340660 )

graphics_toolkit ("gnuplot")
x=linspace(-1,1,11);
y=0;
z=x;
mesh(x,y,z);
colormap([0,0,0]);
print("bad_pdf.pdf", "-dpdfcairo")

====

A gnuplot script tat demonstrates the problem is attached (it contains
binary data).

Both firefox and chrome would render pdf anyway, but evince/xpdf/okular
would not.

I suspect the problem with octave's
colormap([0,0,0])
command here.
But I also think that gnuplot should not produce bad pdf.

Dmitri.
--

Re: 'nohidden3d' option behavior

[sfeam <sf...@us...>]

On Saturday, 28 May 2016 08:55:04 PM Hans-Bernhard Bröker wrote:
> Guys,
> 
> is it possible you've just totally forgotten about 'set surface explicit'?
> 
> It seems 'hidden3d' was never told about it, but in principle, that's 
> the command that should make the change Dan is looking for, i.e. it 
> could sensibly be expected that
> 
> 	set surface explicit
> 	set hidden3d
> 	splot x*y w surface, x*sin(y) w lines
> 
> should yield a plot where the first graph is a hidden (and hiding) 
> surface mesh, whereas the second is not just the usual pair of wire grills.

I think  Dan was looking for options already present in older versions
of gnuplot so that he could produce Octave scripts that did not require
bleeding edge gnuplot support.   

But yes, if we teach the hidden3d code how to deal with a mesh that is not
actually a solid surface, that would be a logical syntax hook to attach it to.
I don't actually know how to do that, so it's pretty hypothetical at this point.

	Ethan

Re: ping : bug #1800 (configure : lua detection is strange when liblua is present but cannot be detected )

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2016/5/29, Sun 13:49
> Subject: Re: ping : bug #1800 (configure : lua detection is strange when liblua is present but cannot be detected )
> 
> On Sunday, 29 May 2016 05:22:30 AM Tatsuro MATSUOKA wrote:
>>  https://sourceforge.net/p/gnuplot/bugs/1800/
>> 
>>  The above seemed to a long lived bug.
>>  I am waiting the response to the bug ticket.
> 
> This does not look like a bug to me.
> 
> The configure script is telling you that the lua library is present, 
> but it can not find the matching lua.h file.
> There are 2 possible reasons.
> 
> 
> 1) It could be because you have not  installed the  *-devel version of the 
> library
> to match the library itself
> 
> On my machine that is liblua5.2-5.2.3  and  lib64lua-devel-5.2.3 
> but you may have a different version.  (The config output you show
> mentions lua5.1).
> 
> 2) Alternatively, you may correctly have the lua.h file installed but it is in 
> a directory not on the default search path.
> That is why the script output suggests
>    configure: WARNING: please add path to lua.h to CPPFLAGS in Makefile
> 
> Of course as you say it is also possible to configure --without-lua
> but then you will not be able to use the tikz terminal.
> It would be better to install or identify the lua.h file.
> 
>     Ethan


Thank you for your reply. I made my response to the bug ticket.
https://sourceforge.net/p/gnuplot/bugs/1800/

Tatsuro

Re: 'nohidden3d' option behavior

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

On 05/28/2016 01:55 PM, Hans-Bernhard Bröker wrote:
> Guys,
>
> is it possible you've just totally forgotten about 'set surface explicit'?

Yes.


> It seems 'hidden3d' was never told about it, but in principle, that's
> the command that should make the change Dan is looking for, i.e. it
> could sensibly be expected that
>
>      set surface explicit
>      set hidden3d
>      splot x*y w surface, x*sin(y) w lines
>
> should yield a plot where the first graph is a hidden (and hiding)
> surface mesh, whereas the second is not just the usual pair of wire grills.

The description for "help set surface" does sound like it will result in 
a transparent mesh.  So, if this were to work as described, then putting 
gnuplot into "set surface explicit" would be close to the behavior I'm 
looking for, except there is no color surface control as is gained by 
pm3d.  It would be nice to eventually just combine pm3d/surface.

Anyway, as you noted, your example doesn't work, but thanks.  Neither 
does pulling the data in from a file:

   set surface explicit
   set hidden3d
   set table 'surfoos'
   splot x*y
   set table 'foomesh'
   splot x*sin(y)
   unset table
   splot 'surfoos' with surface, 'foomesh' with lines

The interesting thing to note about your example and the above is that 
the surface orientation, color-wise, is the opposite direction.  One is 
magenta and blue on "top" surfaces, the other is magenta and blue on 
"bottom" surfaces.  Is that also a bug?

Dan

Re: ping : bug #1800 (configure : lua detection is strange when liblua is present but cannot be detected )

[sfeam <sf...@us...>]

On Sunday, 29 May 2016 05:22:30 AM Tatsuro MATSUOKA wrote:
> https://sourceforge.net/p/gnuplot/bugs/1800/
> 
> The above seemed to a long lived bug.
> I am waiting the response to the bug ticket.

This does not look like a bug to me.

The configure script is telling you that the lua library is present, 
but it can not find the matching lua.h file.
There are 2 possible reasons.

 
1) It could be because you have not  installed the  *-devel version of the library
to match the library itself

On my machine that is liblua5.2-5.2.3  and  lib64lua-devel-5.2.3 
but you may have a different version.  (The config output you show
mentions lua5.1).

2) Alternatively, you may correctly have the lua.h file installed but it is in 
a directory not on the default search path.
That is why the script output suggests
   configure: WARNING: please add path to lua.h to CPPFLAGS in Makefile

Of course as you say it is also possible to configure --without-lua
but then you will not be able to use the tikz terminal.
It would be better to install or identify the lua.h file.

	Ethan

ping : bug #1800 (configure : lua detection is strange when liblua is present but cannot be detected )

[Tatsuro M. <tma...@ya...>]

https://sourceforge.net/p/gnuplot/bugs/1800/

The above seemed to a long lived bug.
I am waiting the response to the bug ticket.

Tatsuro

Re: 'nohidden3d' option behavior

[Hans-Bernhard B. <HBB...@t-...>]

Guys,

is it possible you've just totally forgotten about 'set surface explicit'?

It seems 'hidden3d' was never told about it, but in principle, that's 
the command that should make the change Dan is looking for, i.e. it 
could sensibly be expected that

	set surface explicit
	set hidden3d
	splot x*y w surface, x*sin(y) w lines

should yield a plot where the first graph is a hidden (and hiding) 
surface mesh, whereas the second is not just the usual pair of wire grills.

Re: 'nohidden3d' option behavior

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

On 05/27/2016 03:38 PM, Ethan A Merritt wrote:
> On Wednesday, 25 May, 2016 13:58:32 Daniel J Sebald wrote:
>> On 05/24/2016 11:47 AM, Ethan A Merritt wrote:
>
>>> I still do not see the rationale for selecting "hidden3d" and then turning
>>> it off for a surface.  (Yeah it's a bit confusing that "lines" really means
>>> "surface" in this context).
>>
>> Yes, and I think this is the source of the problem.  Really, what I'm
>> interested in is not technically excluding a mesh "surface" from
>> hidden3d processing but more something that doesn't treat isoline
>> surfaces as being solid--yet those isolines can be hidden by other solid
>> surface elements.  So, that's really what the issue is--i.e., gnuplot
>> automatically casts the wire mesh to solid surface in hidden3d mode.
>
>> That is, one can't have a wire mesh in hidden3d mode.
>
> It turns out that you can, so long as you input the lines in such a
> way that they are not automatically converted into a surface.
>
> For example:
>
> # This doesn't do what you want - both plot elements are treated as surfaces
> set hidden3d
> splot x*y, 3
>
>
> # But if we write out one plot and read it back in as separate lines,
> # the result is different because it is no longer treated as a surface.
>
> set hidden3d
> set table 'foo'
> splot 3
> unset table
> splot x*y, for [i=0:*] 'foo' every 1:1:0:i::i lt 3 lw 3 notitle
>
> Of course since it is not treated as a surface, no isosample lines
> running the other way are generated.  If you want those you have
> to do something clever that transposes x and y at some stage.
> So here goes an example that does exactly what you want:
>
> %%%%%%%%% mesh.dem %%%%%%%%%%%%
>
> set hidden3d
> set xrange [-10:10]
> set yrange [-10:10]
>
> f(x,y) = x*y
> g(x,y) = 3
>
> set table 'foo'
> splot '++' using 1:2:(f($1,$2))
> set table 'baz'
> splot '++' using 2:1:(f($1,$2))
> unset table
> unset key
>
> splot for [i=0:*] 'foo' every 1:1:0:i::i with lines lt 1, \
>        for [i=0:*] 'baz' every 1:1:0:i::i with lines lt 1, \
>        g(x,y) lt 3 lw 3
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>     cheers,
>
>        Ethan
>

I sort of went down this route implementing a "waterfall" plot (i.e., 
isolines in only one direction).  That is, Octave's setting is

>> set(kids, 'meshstyle')
[ {both} | column | row ]

I used the existing code for the 'both' and then implemented either 
column and row by repeating data in pairs (think of a surface having 
zero width).  I suppose I could just toss the 'both' case and implement 
both column and row if 'both' is selected.  That's effectively your example.

I'm working on something else at the moment, but I was going to send a 
short example of waterfall meshes that could be added to the gnuplot 
demos.  Add a more interesting function to your example and 'foo' only 
for one direction, 'baz' only for the other direction, and that's the 
example.

Thanks,

Dan

Re: 'nohidden3d' option behavior

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

On Wednesday, 25 May, 2016 13:58:32 Daniel J Sebald wrote:
> On 05/24/2016 11:47 AM, Ethan A Merritt wrote:

> > I still do not see the rationale for selecting "hidden3d" and then turning
> > it off for a surface.  (Yeah it's a bit confusing that "lines" really means
> > "surface" in this context).
> 
> Yes, and I think this is the source of the problem.  Really, what I'm 
> interested in is not technically excluding a mesh "surface" from 
> hidden3d processing but more something that doesn't treat isoline 
> surfaces as being solid--yet those isolines can be hidden by other solid 
> surface elements.  So, that's really what the issue is--i.e., gnuplot 
> automatically casts the wire mesh to solid surface in hidden3d mode. 

> That is, one can't have a wire mesh in hidden3d mode.

It turns out that you can, so long as you input the lines in such a
way that they are not automatically converted into a surface.

For example:

# This doesn't do what you want - both plot elements are treated as surfaces
set hidden3d
splot x*y, 3


# But if we write out one plot and read it back in as separate lines,
# the result is different because it is no longer treated as a surface.

set hidden3d
set table 'foo'
splot 3
unset table
splot x*y, for [i=0:*] 'foo' every 1:1:0:i::i lt 3 lw 3 notitle

Of course since it is not treated as a surface, no isosample lines
running the other way are generated.  If you want those you have
to do something clever that transposes x and y at some stage.
So here goes an example that does exactly what you want:

%%%%%%%%% mesh.dem %%%%%%%%%%%%

set hidden3d
set xrange [-10:10]
set yrange [-10:10]

f(x,y) = x*y
g(x,y) = 3

set table 'foo'
splot '++' using 1:2:(f($1,$2))
set table 'baz'
splot '++' using 2:1:(f($1,$2))
unset table
unset key

splot for [i=0:*] 'foo' every 1:1:0:i::i with lines lt 1, \
      for [i=0:*] 'baz' every 1:1:0:i::i with lines lt 1, \
      g(x,y) lt 3 lw 3

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

   cheers,

      Ethan

Re: 'nohidden3d' option behavior

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

On 05/24/2016 11:47 AM, Ethan A Merritt wrote:
> On Tuesday, 24 May, 2016 02:13:45 Daniel J Sebald wrote:
>> On 05/23/2016 10:52 PM, sfeam wrote:
>> [snip]
>>> Can you describe what it is you are trying to plot, rather than listing
>>> things that don't work?   I am failing to understand why you would ever
>>> select hidden3d and then draw a surface that doesn't use it.
>>> What is the goal?
>>
>> I looked through the code a bit.  Attached is a short patch that allows
>> LINES to continue onward and corrects what I think is an oversight.  To
>> test, apply the patch, compile and then run something like:
>>
>> set hidden3d front nooffset
>> splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
>> splot x+y with lines nohidden3d
>>
>> This should show lines now (but isolines are missing and I can't figure
>> out why), and in the second splot give a warning but continue on plotting.
>
> I still do not see the rationale for selecting "hidden3d" and then turning
> it off for a surface.  (Yeah it's a bit confusing that "lines" really means
> "surface" in this context).

Yes, and I think this is the source of the problem.  Really, what I'm 
interested in is not technically excluding a mesh "surface" from 
hidden3d processing but more something that doesn't treat isoline 
surfaces as being solid--yet those isolines can be hidden by other solid 
surface elements.  So, that's really what the issue is--i.e., gnuplot 
automatically casts the wire mesh to solid surface in hidden3d mode. 
That is, one can't have a wire mesh in hidden3d mode.

To reiterate, consider if gnuplot had a true hidden surface algorithm 
added to the hidden3d code.  One can think of pm3d or images or patches 
as having solid surfaces as we've sort of added support for those. 
Images and patches though are easy because these are flat and hence work 
within the existing hidden3d framework with just a bit of effort.  If 
there were a hidden3d surface, the current behavior of mesh-with-"unset 
hidden3d" / solid-surface-with-"set hidden3d" could be separated.  That 
is, a mesh would be see-through no matter if it is hidden3d or not 
hidden3d--the nice thing about gnuplot is that it has a unique color per 
side of the mesh that helps comprehend how the surface traverses 3D 
space from the viewer's perspective.  The true hidden surface algorithm 
would then be capable of obstructing the mesh, it's just that the mesh 
doesn't obstruct the view of other things.  [Question, can this 
currently be achieved by the use of alpha-blending with a value of 0? 
Maybe that is what I should be using rather than "nohidden3d".]  If that 
were the way gnuplot behaved, then it would be possible to create the 
current behavior by combining a wire mesh and solid surface using the 
same formula or data on the same plot.


>    So if there is a bug in what you have shown
> so far, I would say it is the treatment of the points in a "linespoints" plot.
> I would expect them to be treated as part of the surface and hence not
> eligible for "nohidden3d".

Yeah, I think I'm coming around to your way of thinking on this. 
"linespoints", "lines", or anything really that has a spatial geometric 
relationship to other objects in the plotting space shouldn't be 
excluded from hidden3d.  I'm wondering whether hidden3d should simply 
always be on by default and we introduce a wire mesh object that does 
not obstruct things behind it.  That is, we'd have a "with surface" and 
"with mesh" which have striking similarity but subtle difference 
regarding hidden3d behavior.  That way, users wouldn't be using the 
global "hidden3d" to fine tune hidden behavior, they'd simply be 
plotting a different type of object.


> I.e.,  I can understand for example wanting to attach "nohidden3d" to
> labels so that a label is visible even if the node it is attached to is
> considered to be on the back of the surface rather than the front of the
> surface.  Similarly for individual points when they are functioning as
> special markers rather than part of the surface grid.
> But I don't see the validity of excluding whole surfaces.
>
> Basically "nohidden3d" is there to handle special cases like labels.
> I would have expected it to be rarely used in practice.  The more common
> problem has been things that are unexpectedly omitted from the hidden3d
> calculation, e.g. images (hidden3d processing added only recently) or
> individual filled polygons defined via "set object".

We've added some of those, but that's possible because of the flat 
surface these have thereby simplifying the hidden3d surface problem.

But yes, for labels, OK.  I mean, I typically am against restricting 
some feature.  That is, gnuplot includes bits of code like

-	    if (this_plot->plot_style == LINES) {
-		this_plot->opt_out_of_hidden3d = FALSE;
-	    }

that make me wonder, Why take that flexibility away from the user?  Just 
let the user handle that.  But I can see now that this feature extended 
to a broader object base would just make a confusing mess of things.

And, again, just for labels this makes sense.  I would think it 
shouldn't be allowed for arrows because that too is confusing--rather 
than the arrow pointing to something on the hidden side of a solid 
surface, it would appear the arrow is pointing to the front of the solid 
surface.  Also, what's the exact intent of having this option for 
labels?  I would think it isn't for having some completely obscured 
arrow/label appearing in front of everything else, but instead something 
where if a label is partially visible or its associated arrow is 
partially visible, the label should be made completely visible (rather 
than possibly not drawn).  Could more clarity be added to the description?

"
   As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
`points`,
   `labels`, `vectors`, and `impulses` even if no surface is present in
the graph.
   Unobscured portions of each vector are drawn as line segments (no
arrowheads).
   Individual plots within the graph may be explicitly excluded from this
   processing by appending the extra option `nohidden3d` to the `with`
specifier.
"

1) Remove the "As of gnuplot version 4.6".  It emphasizes the feature 
making me think this is more broad and significant than it is.

2) "Individual plots within the graph": Is it meant "Individual plots 
having only a type `points`, `labels`, `vectors`, and `impulses`?  As 
opposed to all plots of any type?

3) What does "even if no surface is present in the graph" mean?

4) Might there be a more descriptive word for this option than 
"nohidden3d"?  Is the intended purpose for fine-tuning label behavior of 
those on the border of being or not being obscured by some other solid 
or opaque (i.e., adjusting its drawing order)?

Dan


>
>
> 	Ethan
>
>
>>
>> The reason I think it should be the following (or no test at all, see below)
>>
>>       /* These are handled elsewhere.  */
>>       if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
>> 	return;
>>
>> is that if one looks at where the plot3d_lines_pm3d() function is called
>> in graph3d.c, there's a check on opt_out_of_hidden3d:
>>
>> 		if (draw_this_surface) {
>> 		    if (!hidden3d || this_plot->opt_out_of_hidden3d)
>> 			plot3d_lines_pm3d(this_plot);
>> 		}
>>
>> So, there is a more stringent test within the subroutine than there is
>> in the calling code without the change I'm suggesting.  Note that the
>> same sort of setup exists for plot3d_points(), and there is no test on
>> the hidden property within that routine.  Similarly, there probably
>> doesn't need to be a test at all within plot3d_lines_pm3d() either.  At
>> least one of the items is already confirmed prior to being called.
>>
>> Well, that's about all the change I would want to make for this.  If the
>> attached changes make things clear and seem worth pursuing, I will
>> create a bug report.
>>
>> Dan
>>
>
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: 'nohidden3d' option behavior

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

On Tuesday, 24 May, 2016 02:13:45 Daniel J Sebald wrote:
> On 05/23/2016 10:52 PM, sfeam wrote:
> [snip]
> > Can you describe what it is you are trying to plot, rather than listing
> > things that don't work?   I am failing to understand why you would ever
> > select hidden3d and then draw a surface that doesn't use it.
> > What is the goal?
> 
> I looked through the code a bit.  Attached is a short patch that allows 
> LINES to continue onward and corrects what I think is an oversight.  To 
> test, apply the patch, compile and then run something like:
> 
> set hidden3d front nooffset
> splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
> splot x+y with lines nohidden3d
> 
> This should show lines now (but isolines are missing and I can't figure 
> out why), and in the second splot give a warning but continue on plotting.

I still do not see the rationale for selecting "hidden3d" and then turning
it off for a surface.  (Yeah it's a bit confusing that "lines" really means
"surface" in this context).   So if there is a bug in what you have shown
so far, I would say it is the treatment of the points in a "linespoints" plot.
I would expect them to be treated as part of the surface and hence not
eligible for "nohidden3d".

I.e.,  I can understand for example wanting to attach "nohidden3d" to
labels so that a label is visible even if the node it is attached to is
considered to be on the back of the surface rather than the front of the
surface.  Similarly for individual points when they are functioning as
special markers rather than part of the surface grid.
But I don't see the validity of excluding whole surfaces.

Basically "nohidden3d" is there to handle special cases like labels.
I would have expected it to be rarely used in practice.  The more common
problem has been things that are unexpectedly omitted from the hidden3d
calculation, e.g. images (hidden3d processing added only recently) or
individual filled polygons defined via "set object".


	Ethan


> 
> The reason I think it should be the following (or no test at all, see below)
> 
>      /* These are handled elsewhere.  */
>      if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
> 	return;
> 
> is that if one looks at where the plot3d_lines_pm3d() function is called 
> in graph3d.c, there's a check on opt_out_of_hidden3d:
> 
> 		if (draw_this_surface) {
> 		    if (!hidden3d || this_plot->opt_out_of_hidden3d)
> 			plot3d_lines_pm3d(this_plot);
> 		}
> 
> So, there is a more stringent test within the subroutine than there is 
> in the calling code without the change I'm suggesting.  Note that the 
> same sort of setup exists for plot3d_points(), and there is no test on 
> the hidden property within that routine.  Similarly, there probably 
> doesn't need to be a test at all within plot3d_lines_pm3d() either.  At 
> least one of the items is already confirmed prior to being called.
> 
> Well, that's about all the change I would want to make for this.  If the 
> attached changes make things clear and seem worth pursuing, I will 
> create a bug report.
> 
> Dan
> 

Re: 'nohidden3d' option behavior

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

On 05/23/2016 10:52 PM, sfeam wrote:
[snip]
> Can you describe what it is you are trying to plot, rather than listing
> things that don't work?   I am failing to understand why you would ever
> select hidden3d and then draw a surface that doesn't use it.
> What is the goal?

I looked through the code a bit.  Attached is a short patch that allows 
LINES to continue onward and corrects what I think is an oversight.  To 
test, apply the patch, compile and then run something like:

set hidden3d front nooffset
splot 20*sin(x*y)/(x*y) with lines, x+y with linespoints nohidden3d
splot x+y with lines nohidden3d

This should show lines now (but isolines are missing and I can't figure 
out why), and in the second splot give a warning but continue on plotting.

The reason I think it should be the following (or no test at all, see below)

     /* These are handled elsewhere.  */
     if (plot->has_grid_topology && !plot->opt_out_of_hidden3d && hidden3d)
	return;

is that if one looks at where the plot3d_lines_pm3d() function is called 
in graph3d.c, there's a check on opt_out_of_hidden3d:

		if (draw_this_surface) {
		    if (!hidden3d || this_plot->opt_out_of_hidden3d)
			plot3d_lines_pm3d(this_plot);
		}

So, there is a more stringent test within the subroutine than there is 
in the calling code without the change I'm suggesting.  Note that the 
same sort of setup exists for plot3d_points(), and there is no test on 
the hidden property within that routine.  Similarly, there probably 
doesn't need to be a test at all within plot3d_lines_pm3d() either.  At 
least one of the items is already confirmed prior to being called.

Well, that's about all the change I would want to make for this.  If the 
attached changes make things clear and seem worth pursuing, I will 
create a bug report.

Dan

Re: 'nohidden3d' option behavior

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

On 05/23/2016 10:52 PM, sfeam wrote:
> On Monday, 23 May 2016 07:01:11 PM Daniel J Sebald wrote:
>> On 05/23/2016 06:35 PM, Ethan A Merritt wrote:
>>> On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
>>>> I've read through the documentation for the option "with ...
>>>> nohidden3d".  My initial understanding of the nohidden3d option is that
>>>> it could be a means to individually select what items are included in
>>>> hidden line removal:
>>>>
>>>> "
>>>>     As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
>>>> `points`,
>>>>     `labels`, `vectors`, and `impulses` even if no surface is present in
>>>> the graph.
>>>>     Unobscured portions of each vector are drawn as line segments (no
>>>> arrowheads).
>>>>     Individual plots within the graph may be explicitly excluded from this
>>>>     processing by appending the extra option `nohidden3d` to the `with`
>>>> specifier.
>>>> "
>>>>
>>>> I'm not sure how "even if no surface is present in the graph" is to be
>>>> interpreted.  I take it to mean there is something in plots, currently,
>>>> other than surfaces which can have a 2D subspace that obscures the
>>>> visual field.
>>>>
>>>> More than that though is this phrase "excluded from this processing".
>>>> It's ambiguous as to what "this processing" applies to.
>>>
>>> I'll reply in more detail later, but for now the key thing is that
>>> "this processing" means "sorted together on depth (distance from viewer)".
>>> I.e. even if there are no surfaces to obscure pieces of a vector,
>>> it may still be useful to sort the vectors so that the close ones are
>>> drawn on top of the further ones.
>>
>> OK, I suppose that makes sense.  Typically I think of the hidden3d
>> processing as bisecting or segmenting, but yeah it could be useful to
>> order things.
>>
>>
>>> If you attach the "nohidden3d" attribute to something then it isn't sorted
>>> on depth.  All elements of that unsorted plot will appear in the same layer
>>> (could be in front of; could be behind) the objects that were sorted together.
>>
>> Meaning that the lines of linespoints are disappearing because somehow
>> the algorithm thinks the lines are fully obscured because at every
>> endpoint of the line is covered by a point?  Hence, there are only
>> points left and no edges so the error message?
>>
>> I just altered the code to allow LINES to go on through to the rest of
>> the nohidden3d list.  That still produces an error even though there are
>> no obscuring points coinciding with the lines:
>>
>> [ALTERED CODE RESULT]
>> gnuplot> set samples 20
>> gnuplot> set hidden3d
>> gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
>>            *All* edges undefined or out of range, thus no plot.
>>
>> Well, I can work around the use of "nohidden3d" for what I'm programming
>> by adding some extra logic; it's just that it would be convenient if
>> nohidden3d applied to lines.
>
>
> Can you describe what it is you are trying to plot, rather than listing
> things that don't work?   I am failing to understand why you would ever
> select hidden3d and then draw a surface that doesn't use it.
> What is the goal?

I'm trying to generalize the hidden behavior of lines and surfaces for 
Octave, and for the most part I've got all their demos working now by 
backing off the use of "nohidden3d".  (Originally I thought that option 
applied to mesh lines.)  But Octave's demos are pretty much simple 
single surface/mesh types of things.

The problem of course comes with cases where there are multiple 
surfaces, patches, etc.  Granted, that sort of thing doesn't arise too 
often in practice, but it is a very easy thing to do in something like 
Octave.  Octave treats meshes/surfaces that have no facecolor as 
non-hidden.  So it is conceivable to have one surface that has a 
facecolor and requires hidden line removal while another mesh doesn't.

What would be nice is finer control in gnuplot of what entities should 
have hidden property and what shouldn't.  Also to create groups or 
families of hidden objects.  And then those groups might interact too. 
Add in true hidden surface removal.  Sounds overblown, but sometimes it 
isn't too difficult building an object-oriented hierarchy and leave the 
arrangement up to the user.  Big project.

Anyway, I'm not too concerned about this for the moment now that I have 
reasonably good behavior without the need for "nohidden3d".

Dan

Re: 'nohidden3d' option behavior

[sfeam <sf...@us...>]

On Monday, 23 May 2016 07:01:11 PM Daniel J Sebald wrote:
> On 05/23/2016 06:35 PM, Ethan A Merritt wrote:
> > On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
> >> I've read through the documentation for the option "with ...
> >> nohidden3d".  My initial understanding of the nohidden3d option is that
> >> it could be a means to individually select what items are included in
> >> hidden line removal:
> >>
> >> "
> >>    As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
> >> `points`,
> >>    `labels`, `vectors`, and `impulses` even if no surface is present in
> >> the graph.
> >>    Unobscured portions of each vector are drawn as line segments (no
> >> arrowheads).
> >>    Individual plots within the graph may be explicitly excluded from this
> >>    processing by appending the extra option `nohidden3d` to the `with`
> >> specifier.
> >> "
> >>
> >> I'm not sure how "even if no surface is present in the graph" is to be
> >> interpreted.  I take it to mean there is something in plots, currently,
> >> other than surfaces which can have a 2D subspace that obscures the
> >> visual field.
> >>
> >> More than that though is this phrase "excluded from this processing".
> >> It's ambiguous as to what "this processing" applies to.
> >
> > I'll reply in more detail later, but for now the key thing is that
> > "this processing" means "sorted together on depth (distance from viewer)".
> > I.e. even if there are no surfaces to obscure pieces of a vector,
> > it may still be useful to sort the vectors so that the close ones are
> > drawn on top of the further ones.
> 
> OK, I suppose that makes sense.  Typically I think of the hidden3d 
> processing as bisecting or segmenting, but yeah it could be useful to 
> order things.
> 
> 
> > If you attach the "nohidden3d" attribute to something then it isn't sorted
> > on depth.  All elements of that unsorted plot will appear in the same layer
> > (could be in front of; could be behind) the objects that were sorted together.
> 
> Meaning that the lines of linespoints are disappearing because somehow 
> the algorithm thinks the lines are fully obscured because at every 
> endpoint of the line is covered by a point?  Hence, there are only 
> points left and no edges so the error message?
> 
> I just altered the code to allow LINES to go on through to the rest of 
> the nohidden3d list.  That still produces an error even though there are 
> no obscuring points coinciding with the lines:
> 
> [ALTERED CODE RESULT]
> gnuplot> set samples 20
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
>           *All* edges undefined or out of range, thus no plot.
> 
> Well, I can work around the use of "nohidden3d" for what I'm programming 
> by adding some extra logic; it's just that it would be convenient if 
> nohidden3d applied to lines.


Can you describe what it is you are trying to plot, rather than listing
things that don't work?   I am failing to understand why you would ever
select hidden3d and then draw a surface that doesn't use it.
What is the goal?

	Ethan

Re: 'nohidden3d' option behavior

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

On 05/23/2016 06:35 PM, Ethan A Merritt wrote:
> On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
>> I've read through the documentation for the option "with ...
>> nohidden3d".  My initial understanding of the nohidden3d option is that
>> it could be a means to individually select what items are included in
>> hidden line removal:
>>
>> "
>>    As of gnuplot version 4.6, hidden3d also affects 3D plotting styles
>> `points`,
>>    `labels`, `vectors`, and `impulses` even if no surface is present in
>> the graph.
>>    Unobscured portions of each vector are drawn as line segments (no
>> arrowheads).
>>    Individual plots within the graph may be explicitly excluded from this
>>    processing by appending the extra option `nohidden3d` to the `with`
>> specifier.
>> "
>>
>> I'm not sure how "even if no surface is present in the graph" is to be
>> interpreted.  I take it to mean there is something in plots, currently,
>> other than surfaces which can have a 2D subspace that obscures the
>> visual field.
>>
>> More than that though is this phrase "excluded from this processing".
>> It's ambiguous as to what "this processing" applies to.
>
> I'll reply in more detail later, but for now the key thing is that
> "this processing" means "sorted together on depth (distance from viewer)".
> I.e. even if there are no surfaces to obscure pieces of a vector,
> it may still be useful to sort the vectors so that the close ones are
> drawn on top of the further ones.

OK, I suppose that makes sense.  Typically I think of the hidden3d 
processing as bisecting or segmenting, but yeah it could be useful to 
order things.


> If you attach the "nohidden3d" attribute to something then it isn't sorted
> on depth.  All elements of that unsorted plot will appear in the same layer
> (could be in front of; could be behind) the objects that were sorted together.

Meaning that the lines of linespoints are disappearing because somehow 
the algorithm thinks the lines are fully obscured because at every 
endpoint of the line is covered by a point?  Hence, there are only 
points left and no edges so the error message?

I just altered the code to allow LINES to go on through to the rest of 
the nohidden3d list.  That still produces an error even though there are 
no obscuring points coinciding with the lines:

[ALTERED CODE RESULT]
gnuplot> set samples 20
gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines nohidden3d
          *All* edges undefined or out of range, thus no plot.

Well, I can work around the use of "nohidden3d" for what I'm programming 
by adding some extra logic; it's just that it would be convenient if 
nohidden3d applied to lines.

Dan

Re: 'nohidden3d' option behavior

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

On Monday, 23 May, 2016 18:24:39 Daniel J Sebald wrote:
> I've read through the documentation for the option "with ... 
> nohidden3d".  My initial understanding of the nohidden3d option is that 
> it could be a means to individually select what items are included in 
> hidden line removal:
> 
> "
>   As of gnuplot version 4.6, hidden3d also affects 3D plotting styles 
> `points`,
>   `labels`, `vectors`, and `impulses` even if no surface is present in 
> the graph.
>   Unobscured portions of each vector are drawn as line segments (no 
> arrowheads).
>   Individual plots within the graph may be explicitly excluded from this
>   processing by appending the extra option `nohidden3d` to the `with` 
> specifier.
> "
> 
> I'm not sure how "even if no surface is present in the graph" is to be 
> interpreted.  I take it to mean there is something in plots, currently, 
> other than surfaces which can have a 2D subspace that obscures the 
> visual field.
> 
> More than that though is this phrase "excluded from this processing". 
> It's ambiguous as to what "this processing" applies to. 

I'll reply in more detail later, but for now the key thing is that
"this processing" means "sorted together on depth (distance from viewer)".
I.e. even if there are no surfaces to obscure pieces of a vector,
it may still be useful to sort the vectors so that the close ones are
drawn on top of the further ones.  

If you attach the "nohidden3d" attribute to something then it isn't sorted
on depth.  All elements of that unsorted plot will appear in the same layer
(could be in front of; could be behind) the objects that were sorted together.

	Ethan



> There are two 
> ways to take this:
> 
> 1) "nohidden3d" applies to any object because "individual plots" would 
> include anything.
> 
> 2) "nohidden3d" only applies to points, labels, vectors and impulses.
> 
> My initial thought was that 1 is the case, but the current version of 
> gnuplot does nothing to "with lines" objects when 'with ... nohidden3d' 
> is specified.  The "with lines nohidden3d" still has hidden3d effects. 
> So, 2 seems more the case and to confirm that, here is the code from 
> plot3d.c:
> 
> 	    /* Rule out incompatible line/point/style options */
> 	    if (this_plot->plot_type == FUNC3D) {
> 		if ((this_plot->plot_style & PLOT_STYLE_HAS_POINT)
> 		&&  (this_plot->lp_properties.p_size == PTSZ_VARIABLE))
> 		    this_plot->lp_properties.p_size = 1;
> 	    }
> 	    if (this_plot->plot_style == LINES) {
> 		this_plot->opt_out_of_hidden3d = FALSE;
> 	    }
> 
> My thought on this is, Why exclude lines from the "nohidden3d" option? 
> If no hidden 3d processing is done on the surface lines, would that pose 
> a problem?  Also, "LINES" is excluded, but why then not "LINESPOINTS"?
> 
> Just to illustrate, try these plots:
> 
> gnuplot> set samples 20
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lines nohidden3d
> 
> The above just illustrates that "lines" is unaffected by "nohidden3d". 
> Now try
> 
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp nohidden3d
> 
> So, linespoints is affected.  However, although the points behave as 
> expected, the lines have disappeared.  Why should the lines disappear? 
> I would think the second plot should look very similar to this result:
> 
> gnuplot> unset hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp
> 
> Again to illustrate the disappearing lines, try:
> 
> gnuplot> set hidden3d
> gnuplot> splot 20*sin(x*y)/(x*y) with linespoints nohidden3d
>           *All* edges undefined or out of range, thus no plot.
> 
> Maybe the current behavior isn't the intended behavior, but I'm not 
> fully comprehending the nohidden3d option.
> 
> Dan
> 
> 
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

'nohidden3d' option behavior

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

I've read through the documentation for the option "with ... 
nohidden3d".  My initial understanding of the nohidden3d option is that 
it could be a means to individually select what items are included in 
hidden line removal:

"
  As of gnuplot version 4.6, hidden3d also affects 3D plotting styles 
`points`,
  `labels`, `vectors`, and `impulses` even if no surface is present in 
the graph.
  Unobscured portions of each vector are drawn as line segments (no 
arrowheads).
  Individual plots within the graph may be explicitly excluded from this
  processing by appending the extra option `nohidden3d` to the `with` 
specifier.
"

I'm not sure how "even if no surface is present in the graph" is to be 
interpreted.  I take it to mean there is something in plots, currently, 
other than surfaces which can have a 2D subspace that obscures the 
visual field.

More than that though is this phrase "excluded from this processing". 
It's ambiguous as to what "this processing" applies to.  There are two 
ways to take this:

1) "nohidden3d" applies to any object because "individual plots" would 
include anything.

2) "nohidden3d" only applies to points, labels, vectors and impulses.

My initial thought was that 1 is the case, but the current version of 
gnuplot does nothing to "with lines" objects when 'with ... nohidden3d' 
is specified.  The "with lines nohidden3d" still has hidden3d effects. 
So, 2 seems more the case and to confirm that, here is the code from 
plot3d.c:

	    /* Rule out incompatible line/point/style options */
	    if (this_plot->plot_type == FUNC3D) {
		if ((this_plot->plot_style & PLOT_STYLE_HAS_POINT)
		&&  (this_plot->lp_properties.p_size == PTSZ_VARIABLE))
		    this_plot->lp_properties.p_size = 1;
	    }
	    if (this_plot->plot_style == LINES) {
		this_plot->opt_out_of_hidden3d = FALSE;
	    }

My thought on this is, Why exclude lines from the "nohidden3d" option? 
If no hidden 3d processing is done on the surface lines, would that pose 
a problem?  Also, "LINES" is excluded, but why then not "LINESPOINTS"?

Just to illustrate, try these plots:

gnuplot> set samples 20
gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lines nohidden3d

The above just illustrates that "lines" is unaffected by "nohidden3d". 
Now try

gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp nohidden3d

So, linespoints is affected.  However, although the points behave as 
expected, the lines have disappeared.  Why should the lines disappear? 
I would think the second plot should look very similar to this result:

gnuplot> unset hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with lines, x+y with lp

Again to illustrate the disappearing lines, try:

gnuplot> set hidden3d
gnuplot> splot 20*sin(x*y)/(x*y) with linespoints nohidden3d
          *All* edges undefined or out of range, thus no plot.

Maybe the current behavior isn't the intended behavior, but I'm not 
fully comprehending the nohidden3d option.

Dan