Hi !
I'm using the latest gnuplot package for debian, version 6.0 patchlevel 2.
I have the data.dat data. I use a script to plot the data for 1 point, 2 points, 3 points etc in order to produce the frames for a video. The results are .png files in a frames folder. The idea is to produce a climate spiral going up and getting hotter as it is more "outwards".
The script is this one (I tried to remove what is superfluous to the bug reproduction) :
#! /usr/bin/gnuplot -c
set term pngcairo size 400,400
set xrange [-3.2:3.2]
set yrange [-3.2:3.2]
set zrange [0:800]
set cbrange [-1:1]
PI=3.14159
step=2*PI/12
x(r,n)=r*cos(n*step)
y(r,n)=r*sin(n*step)
res=1
do for [i=40:80] {
outfile=sprintf('frames/%04d.png',i)
set output outfile
splot 'data.dat' every ::0::i u (x($2+1,$1*-1+4)):(y($2+1,$1*-1+4)):($0*2):2 w l lw 4.5 lc palette not
}
I simply launch it with ./fig17.gp.
Sometimes the lines are drawn in what seems to be the wrong order. Some lines that correspond to early values in the datafile appear "over" newer lines. It is particularly visible on frames 47, 48 and 71. I have reproduced the bug with the png, pngcairo and webp terminals.
I don't know much about gnuplot and even less about the command splot, the error might be on my side.
Have a nice day,
Arthur
Line segments are by default drawn in the order they are encountered in the data. In your case you probably want to sort the line segments along the line of sight and draw them from back to front. You can do this by adding a command
set hidden3dbefore the splot command (I would put it at the top with the range commands).Note that the
set hidden3dalgorithm is not fool-proof when used this way, as it is possible to construct a series of lines that defy any simple ordering that prevents occlusion (e.g. A overlaps B which overlaps C which overlaps D which overlaps A). I think your example data does not suffer from this, but if you do run into such a problem it would help to break the line segments into smaller pieces.