Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-11 16:52:15
|
[moving this to the mailing list for discussion] I wrote> > This patchset adds a qsort() of the points in a 3D > plot, so that you get proper occlusion of distant > points by close points. The improvement is particularly > noticible for large solid points. See for example the > plots in rgb_variable.dem Petr Mikulik replied> > The series of points can be a time sequence, and there it > would be useful to draw them (into a map) as they appear in > the data file, without ordering. I do not understand this example. Could you explain what the x, y, and z coordinates would be in this case? Let me clarify that the sort operation only applies to the order in which the points are drawn on the screen. It does not change their connectivity or ordering within the plot. So if you draw in style "with linespoints" the lines will still run from point 1 to point 2 to point 3 and so on, regardless of their relative Z values in the current view. However, if point 2 is closer to the viewer than points 1 and 3, it will occlude them. Of course in that case the line segments will not be sorted, even though their endpoints are. The result is imperfect, but is better than what we have now. However, I am having second thoughts about whether it is worth adding this sort operation outside of the hidden3d code. It does not handle the general case of mixing points from multiple sources into one plot. Suppose you are inspecting two sets of 3D data points, hoping to find that one set clusters in a different region of 3-space than the other. gnuplot> splot "class1" with points, "class2" with points The patch I posted would sort the "class1" points relative to each other, and the "class2" points relative to each other, but all the points from class2 will occlude all of the points from class1 because they are drawn afterwards. Not good. So even though the simple sort patchset was useful to me for the specific plots I was trying to make last week, I think that the longer term plan should be to extend the category of plots handled by "set hidden3d". In particular the hidden3d code could sort points and line segments even if there is no surface present, and it could track the full set of properties associated with each point or line segment. I am not clear on how this would fit in with Johannes Zellner's patch #1077726 "true depth ordering for pm3d plots". Have you looked at that patchset? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-10-11 19:05:42
|
>> The series of points can be a time sequence, and there it >> would be useful to draw them (into a map) as they appear in >> the data file, without ordering. > > I do not understand this example. Could you explain what the > x, y, and z coordinates would be in this case? The data will be drawn as a color map (set view map). x, y - coordinate z - colour line number in the file = this gives the z-order, which point is drawn the last Example: data file contains several scans (through angles, for example) of scattered intensity, the sample has been measured several times, and I want to see the latest values -- thus the previous have to be hidden below the latest data. I use this "overlapping" when measuring scattered intensity in regions of reciprocal space of a sample with and without absorber, and overlapping that part which has better statistics. If gnuplot sorts the data, that would destroy the image. (Or, one would have to be think that the z-coordinate is $0, not $3). > the longer term plan should be to extend the category of > plots handled by "set hidden3d". In particular the hidden3d code > could sort points and line segments even if there is no surface The trouble of hidden3d is that it is a global filter, not an option for the plot style. Having the sort as an option, it would be more convenient. > I am not clear on how this would fit in with Johannes Zellner's > patch #1077726 "true depth ordering for pm3d plots". > Have you looked at that patchset? Yes. It is reordering the facets (quadrangles) same way as you do here for points. Both are useful for a nice visualization of surfaces. For "maps", it would bring processing artefacts to overlapping regions. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-11 20:45:14
|
On Tuesday 11 October 2005 12:05 pm, Petr Mikulik wrote: > >> The series of points can be a time sequence, and there it > >> would be useful to draw them (into a map) as they appear in > >> the data file, without ordering. > > > > I do not understand this example. Could you explain what the > > x, y, and z coordinates would be in this case? > > The data will be drawn as a color map (set view map). > x, y - coordinate > z - colour > > Example: data file contains several scans (through angles, for example) of > scattered intensity, the sample has been measured several times, and I want > to see the latest values -- thus the previous have to be hidden below the > latest data. OK. I understand. > (Or, one would have to be think that the z-coordinate is $0, not $3). Yes, that would work: set view map plot "series" using 1:2:0:3 with linespoints palette The sort is on $0, but the color is taken from column 3. That works fine for "set view map", although I admit that it is a change from previous behavior. But it doesn't work to retrace curves in the general 3D case (not "set view map"). So yes, I see that there must be some way to toggle the sort on and off. > The trouble of hidden3d is that it is a global filter, not an option for the > plot style. The property of being global is exactly what you need in order to do Z-ordering for multiplot datasets within the same plot. Otherwise the later plots will always occlude the earlier ones. > > I am not clear on how this would fit in with Johannes Zellner's > > patch #1077726 "true depth ordering for pm3d plots". > > Yes. It is reordering the facets (quadrangles) same way as you do here for > points. Both are useful for a nice visualization of surfaces. But you could not mix them in the same graph unless they were both moved into the global hidden3d code, right? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-10-12 11:39:33
|
Petr Mikulik wrote: > The trouble of hidden3d is that it is a global filter, not an option for > the plot style. That's not a trouble, that's a necessity. It makes absolutely no sense whatsoever to draw one dataset hidden-lined, but another one directly. This distinguishes hidden3d from essentially all other current or former global splot filters (dgrid3d, contouring, pm3d). Hidden-lining is, by definition, a property of the plot at large, not of the individual dataset. |
