Menu
▾
▴
5 Attachments
#1612 Contours not corrected dashed
Rendering contour lines with dashed lines (e.g. dt 2 or dt 3) does not correctly dash lines -- they are solid in some places.
I've tested this by using "set table" to output the contour data, then plotting it with the same dash type. I've attached the script and dataset.
Tested with wxt and svg terminals using gnuplot 5.0 patchlevel 0
Diff:
The interpolated points on the contour seem to get connected not by one continous line but individual lines, making the dash pattern restart at every point. Following plot reproduces the same problem.
(I'll set up a feature request addressing the ugly sampling in my example, that's not easily fixable.)
Last edit: Karl Ratzsch 2015-05-17
As Karl notes, the issue is that for many output devices (a.k.a. terminals) the dash pattern only comes out right for single continuous lines, not for a collection of end-to-end line segments. The contouring algorithm is an one example of this effect, some of the curve-smoothing routines also illustrate this problem.
A possible workaround is to use "set table" to write the contours out to a file, then read the file back in in a separate plot command. This bypasses the problem by collecting the line segments making up a contour into longer "polylines" that suffer fewer artifacts from dash pattern code.
I noticed that in table mode, "splot .. nosurface" still prints the gridded data (+the contour)? Issuing "unset surface" before works as expected.
Table mode is pretty dumb. It bypasses most of the plot-specific details and just dumps the stored coordinates.
A fix for this problem is now in cvs for 5.0 and 5.1. It will be included in the release package for 5.0.1, which will happen real soon now.
I noticed one other hitch with contour lines: The colour can be controlled via "set linetype", but not dashtypes and linewidths. Those settings are simply ignored.
Dashed contour lines in epslatex terminal with current 5.2.0 plus patch enabling dashtypes. Does not look like the dashed contour lines work yet here.
"Ethan Merritt" sfeam@users.sf.net writes:
Looks like something that should not really be left to the discretion of
the terminal, or the likes of issue 1612 will get redone time and again.
At any rate, this is kind of important for getting useful graphics and
it would be a real annoyance if at this stage in generation of my plots
I had to restart from scratch using a different graphics program. Any
suggestions what I might try here instead?
--
David Kastrup
Oh, and to nib one idea in the bud: the tikz terminal suffers from the same symptom. And to add insult to injury, Gnuplot 4.6's epslatex terminal in dashed mode (apart from rather random assignments of colors, including different colors for parts of the same contour height) does not dash well, either: basically if you have a zigzagging line, some directions are dashed, the opposite direction may be not. While it doesn't appear to have the restarting dash pattern problem, dash patterns don't work in some directions.
Dashed lines and gnuplot's current hidden3d mode are intrinsically incompatible. it is not specific to contour lines. In order to figure out which bits of the scene occlude which other bits of the scene, all of the line segments making up all the scene elements are sorted along the line of sight so that only the top line segment (closest to the viewer) is kept. This means that all of the little line segments making up a single longer line, for example a contour line, get separated from each other. When they are then drawn one by one the fractional progress through a dot-dash pattern is lost.
I do not see a way around this given the current set of algorithms that have been implemented.
About the only alternative that occurs to me would be to treat every dot or dash making up the line as a separate object rather than as part of a vector. I.e. instead of drawing a dotted line, the program would place N separate dots along the path where the line would have been. But no such drawing mode currently exists in gnuplot.
Sounds to me like all that would be required is almost-drawing everything once without starting the hidden3d algorithm and recording for each line piece the starting phase of the dash pattern (possibly just accumulated line length will be precise enough for most practical purposes if the exact pattern length to be used is not yet known). Then you can sort and redraw in arbitrary order.
That would not require a significant adaptation of the algorithms, just recording some additional information while working with the current "workhorse" algorithms.
Actually, for base contours I'd expect the contours to be completely below the surface and planar, so just drawing them unsorted first before starting with the surface should suffice for most (if not all) workloads.
Any chance to do this drawing contours (without hidden3d) and surface (with hidden3d) in separate commands, combined into one graphic? I haven't quite got the hang of how replot works.