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