#331 Revisiting hidden3d+samples/isosamples using contours
I recently opened a thread discussing the behavior of samples/isosamples with the option hidden3d enabled. My normal use case is to set samples at a multiple of isosamples so that the mesh suggests the shape of the plot with high resolution, without including too many liness that clutter the graph. Due the way hidden3d currently works, however, it is impossible for the line to interpolate between line intersections the way splot works without the hidden3d option. I've been tinkering around with the code, and it is enormously complex. However, I wonder the following: it is currently possible to use hidden3d on contour lines, which are interpolated based on "samples" instead of "isosamples". If the contour lines can be properly hidden with a high sampling rate, then it MUST be possible for mesh lines to do the same.
I would handle this myself, but the code is inscrutable. Could someone more knowledgeable examine this case and give some feedback on its feasibility?
A link to the previous thread: https://sourceforge.net/tracker/?func=detail&atid=352055&aid=3523126&group_id=2055
You're still not getting what the problem actually is. Yes, arbitrary lines can be hidden behind a surface by hidden3d mode --- arrows, contours, you name it. But arbitrary lines like those cannot _form_ a surface, and without a surface, there's nothing for anything to hide behind.
For this reason hidden3d needs grid-structured input. For files, that means the data itself has to be grid-structured. For functions, that means it has to be restricted to the more regular input provided by isosamples only.
Oh, and BTW, you're less than totally correct about contouring, too. The input to contouring is actually sampled based on isosamples, too. To be more precise, the input to contouring is the samples_x * iso_2 grid, i.e. essentially half of the data that makes up the normal surface plot. The only real difference between hidden3d and contouring in this case is that hidden3d uses iso_1 instead of samples_x.
Hans-Bernhard,
Thanks for your response, but there's still something that confuses me: Let's say we set samples and isosamples to
set isosamples 50
set samples 50
set hidden 3d
plot f(x,y) w l
Those lines look great and they are properly hidden. However, there are too many, which would seem to be resolved by
set isosamples 10
which, as we've established, now makes jagged lines. Why wouldn't it be possible to do the standard hidden3d routine with 50 isosample points in each dimension, and then simply NOT PLOT 4-out-of-5 lines? This would achieve the same effect that I'm looking for, that is, fewer and smoother lines. In addition the result be more consistent with non-hidden3d behavior and be more attractive to boot.
The hidden3d routines do not track lines. They track the individual little rectangles making up a grid. There is no point in the current process where you could insert a decision "draw this line" or "don't draw this line".
The closest I can think of to what you describe would involve drawing a finely gridded hidden3d surface in background color, then mixing in individual colored lines whose z coordinate is displaced towards the viewer by some small amount.
The problem with that idea is that it destroys the relation between the surface that hides stuff behind itself, and the lines you draw to show the surface. In other words, roughly half of your pretty lines would disappear behind their own surface. That display would make no sense whatsoever.
I may have been unclear. Let me illustrate with an example. There is no code in place to displace a line toward the viewer in the general case, so this example only works if the line of sight is in the xz plane so that displacement along x is toward the viewer.
Output from these commands is attached as a PNG file
set hidden3d
set isosamples 50,50
set view 70, 90, 1.27, 0.76
set xyplane at -0.2
splot sinc((y*y + (x+.01)**2)/10.) lw .5 lc rgb "grey", \ sinc((x-3)**2<.1 ? (y*y + (x-.01)**2)/10. : NaN) lw 2 lc rgb "blue", \ sinc(x**2<.1 ? (y*y + (x-.01)**2)/10. : NaN) lw 2 lc rgb "red"
png output from the proof-of-principle demo
Here's a solution I found that gave spectacular results, and feel free to see the attached image that results. One question I have is: somehow the way I'm doing this, I can't get the lines flush with the plot-range boundaries? Also note that the attached image is using my new normal shading patch, which I will update with a new version that incorporates "set pm3d depthorder".
set view 82, 15
set zrange [0:12]
a=1.0
t = 2.7
set cbrange [-3*t:3*t]
g(x,y) = 2*cos(sqrt(3)*y*a)+4*cos(sqrt(3)/2.0*y*a)*cos(3*x*a/2.0)
f(x,y) = t*sqrt(3+g(1.0/sqrt(3)*y,1.0/sqrt(3)*(-x)))
set sample 500
set isosamples 500
xmin = -2*pi/a
xmax = 2*pi/a
ymin = -sqrt(3)*pi/a
ymax = sqrt(3)*pi/a
set xrange [xmin:xmax]
set yrange [ymin:ymax]
set ztics 2
set cbtics 2
#set zlabel 'Energy' rotate by 90
#set xlabel 'k_x'
#set ylabel 'k_y'
unset zlabel
unset xlabel
unset ylabel
unset xtics
unset ytics
unset ztics
unset colorbox
unset border
set hidden3d
unset key
set terminal pngcairo transparent size 5*800, 3.5*800
set output 'graphene.png'
#set terminal x11
set isosamples 200
set samples 200
set pm3d corners2color normal
set hidden3d front
set style line 10 lt -1 lw 3
N_LINES = 10.0
DELTA = 2e-2
set multiplot
splot '++' u 1:2:(f($1,$2)) w pm3d, '++' u 1:2:(f($1,$2)-DELTA) w l lt -2, \ for [i=xmin:xmax:(xmax-xmin)/N_LINES] '+' u (i):1:(f(i,$1)) w l ls 10, \ for [i=ymin:ymax:(ymax-ymin)/N_LINES] '+' u 1:(i):(f($1,i)) w l ls 10
splot '++' u 1:2:(f($1,$2)+DELTA) w l lt -2, \ for [i=xmin:xmax:(xmax-xmin)/N_LINES] '+' u (i):1:(f(i,$1)) w l ls 10, \ for [i=ymin:ymax:(ymax-ymin)/N_LINES] '+' u 1:(i):(f($1,i)) w l ls 10
unset multiplot
smooth mesh using "plot for" loops
> I may have been unclear. Let me illustrate with an example.
I may have been unclear which post I've been referring to --- the tracker lacks quoting mechanisms. I was referring to Douglas' post of 2012-06-03 08:02:39 PDT.