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