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
>