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