Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-20 03:19:01
|
Can anyone explain to me why the two surfaces produced by the command below are colored so differently? splot x with pm3d, y with pm3d The "y" surface is colored smoothly, but the "x" surface is colored in 9 increments only. What command would I use to get two smoothly colored surfaces? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-11-20 06:39:32
|
Ethan A Merritt wrote: > Can anyone explain to me why the two surfaces produced > by the command below are colored so differently? > > splot x with pm3d, y with pm3d > > The "y" surface is colored smoothly, but the "x" > surface is colored in 9 increments only. > What command would I use to get two smoothly > colored surfaces? I assume that is a bug. I created a PDF example, and zooming in using a viewer shows the first draw (x) has a larger color map than the second draw (y). So this is not terminal dependent. Furthermore, if a third function is added to the plot, it too has a low resolution color map. So the first map is drawn probably correct and the map for functions afterward is incorrect. Furthermore, replot results in the first function being correct again, so it is reset between replots. Using a fprintf(), I believe that "make_palette" is called just once. Also, I don't think the function is being cast to an integer anywhere because then we'd see 20 levels (-10 to 10) rather than just ten. Petr, could there be a conversion problem in z2cb(), cb2gray() or set_color()? Dan |
|
From: Juergen W. <wie...@fr...> - 2005-11-20 07:27:13
|
Ethan A Merritt wrote: > Can anyone explain to me why the two surfaces produced > by the command below are colored so differently? > > splot x with pm3d, y with pm3d > > The "y" surface is colored smoothly, but the "x" > surface is colored in 9 increments only. > What command would I use to get two smoothly > colored surfaces? This is a sampling issue. For the x-lines (scan lines) the setting of "set samples" is used while for the y-lines the "set isosamples" setting applies. This can be useful for surface plots, where the x-lines will be smooth and adjacent x-lines are linearly connected a few times. For pm3d this does not seem to be optimal. Juergen |
|
From: Daniel J S. <dan...@ie...> - 2005-11-20 08:23:37
|
Juergen Wieferink wrote: > Ethan A Merritt wrote: > >>Can anyone explain to me why the two surfaces produced >>by the command below are colored so differently? >> >> splot x with pm3d, y with pm3d >> >>The "y" surface is colored smoothly, but the "x" >>surface is colored in 9 increments only. >>What command would I use to get two smoothly >>colored surfaces? > > > This is a sampling issue. For the x-lines (scan lines) the setting > of "set samples" is used while for the y-lines the "set isosamples" > setting applies. This can be useful for surface plots, where the > x-lines will be smooth and adjacent x-lines are linearly connected > a few times. For pm3d this does not seem to be optimal. Oh yeah. Interchanging x and y in the example still results in the same sampling relationship, only one surface order is interchanged. Hmm, I guess I'm not following how this is useful for surface plots. Why should one dimension have any different meaning than the other dimension unless the user programs it to be that way? Is there an example in the demos somewhere that we can look at? So, I think I see what controls that, Ethan: set isosamples 128 And by default it is 10. Now, am I understanding correctly that the isolines controls both the mesh spacing of the surface plot and the color gradient spacing of the pm3d? (Nothing in "help set isosamples" seems to suggest that.) If so, we should maybe discuss if that is good or bad. First it seems a bit confusing, or should I say non-obvious. Could independent parameters be less confusing? (Or the same parameter with qualifiers "surface" and "pm3d" somehow? E.g., "set surface isosamples", "set pm3d isosamples".) Second, I could imagine a case where you wouldn't want those tied together. A lot of times people (like me) are concerned with adequately sampling a function or signal. Say one wanted to plot a function as a pm3d color "surface" and lay a mesh surface over the top to represent where the sampling locations might be. If "pm3d isosamples" is higher than the "surface isosamples" one may get insight to whether the sampling chosen is high enough resolution, i.e. greater than the Nyquist rate. On the other hand, if the two are always tied together, it's not so useful that way. Dan |
|
From: Johannes Z. <joh...@ze...> - 2005-11-20 10:06:00
|
On Sun, Nov 20, 2005 at 02:30:56AM -0600, Daniel J Sebald wrote:
> Juergen Wieferink wrote:
> >Ethan A Merritt wrote:
> >
> >>Can anyone explain to me why the two surfaces produced
> >>by the command below are colored so differently?
> >>
> >> splot x with pm3d, y with pm3d
> >>
> >>The "y" surface is colored smoothly, but the "x"
> >>surface is colored in 9 increments only.
> >>What command would I use to get two smoothly
> >>colored surfaces?
> >
> >
> >This is a sampling issue. For the x-lines (scan lines) the setting
> >of "set samples" is used while for the y-lines the "set isosamples"
> >setting applies. This can be useful for surface plots, where the
> >x-lines will be smooth and adjacent x-lines are linearly connected
> >a few times. For pm3d this does not seem to be optimal.
>
> Oh yeah. Interchanging x and y in the example still results in the same
> sampling relationship, only one surface order is interchanged.
>
> Hmm, I guess I'm not following how this is useful for surface plots. Why
> should one dimension have any different meaning than the other dimension
> unless the user programs it to be that way? Is there an example in the
> demos somewhere that we can look at?
>
> So, I think I see what controls that, Ethan:
>
> set isosamples 128
>
> And by default it is 10.
>
> Now, am I understanding correctly that the isolines controls both the mesh
> spacing of the surface plot and the color gradient spacing of the pm3d?
> (Nothing in "help set isosamples" seems to suggest that.) If so, we should
> maybe discuss if that is good or bad.
>
> First it seems a bit confusing, or should I say non-obvious. Could
> independent parameters be less confusing? (Or the same parameter with
> qualifiers "surface" and "pm3d" somehow? E.g., "set surface isosamples",
> "set pm3d isosamples".)
If you think of "samples" and "isosamples" converting functions into data
points it's totally obvious. It's pretty straightforward that pm3d uses
the same sampling as any other plotting styles do. gnuplot offers just
one sampling which is common for all plots.
> Second, I could imagine a case where you wouldn't want those tied together.
> A lot of times people (like me) are concerned with adequately sampling a
> function or signal. Say one wanted to plot a function as a pm3d color
> "surface" and lay a mesh surface over the top to represent where the
> sampling locations might be. If "pm3d isosamples" is higher than the
> "surface isosamples" one may get insight to whether the sampling chosen is
> high enough resolution, i.e. greater than the Nyquist rate. On the other
> hand, if the two are always tied together, it's not so useful that way.
There might be cases where you want a different sampling for different
plotting styles. To be more rigorous: there might be cases where
different PLOTS should be sampled differently, something like
splot f(x, y) sampling 50:70 w pm3d, g(x, y) sampling 20:20 w lines
--
Johannes
|
|
From: Johannes Z. <joh...@ze...> - 2005-11-20 15:22:35
|
On Sat, Nov 19, 2005 at 07:18:55PM -0800, Ethan A Merritt wrote: > Can anyone explain to me why the two surfaces produced > by the command below are colored so differently? > > splot x with pm3d, y with pm3d > > The "y" surface is colored smoothly, but the "x" > surface is colored in 9 increments only. > What command would I use to get two smoothly > colored surfaces? btw.: did you see the usefulness of the "set pm3d depth" patch with such intersecting surfaces? -- Johannes |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-20 18:59:04
|
On Sunday 20 November 2005 07:22 am, Johannes Zellner wrote:
> On Sat, Nov 19, 2005 at 07:18:55PM -0800, Ethan A Merritt wrote:
> > Can anyone explain to me why the two surfaces produced
> > by the command below are colored so differently?
> >
> > splot x with pm3d, y with pm3d
>
> btw.: did you see the usefulness of the "set pm3d depth" patch with
> such intersecting surfaces?
That was, in fact, why I drew this plot in the first place.
I was trying to determine if there were any artifacts near the
line of intersection, but I got distracted by the coloring
glitch.
Have you figured out any reason why the "set hidden3d"
apparently runs much slower on your machines than on mine?
If there really is a speed bottleneck in the code, I'd like
to try to pin it down and fix it. Then we can go back to
discussing if there are any other drawbacks to merging your
pm3d sort code with the general hidden3d capability.
I hope the following conceptual example makes it clear why
I think this would be useful:
f(x,y) = theory1_prediction(x,y)
g(x,y) = theory2_prediction(x,y)
set hidden3d
splot f(x,y) with pm3d, g(x,y) with pm3d, \
"experiment" using 1:2:3 with points pointsize 3 pt 6
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Johannes Z. <joh...@ze...> - 2005-11-20 19:41:25
|
On Sun, Nov 20, 2005 at 10:58:48AM -0800, Ethan A Merritt wrote: [...] > Have you figured out any reason why the "set hidden3d" > apparently runs much slower on your machines than on mine? The comparison depends pretty much on the sampling rate. Try to run the attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my machine the pm3d correctly ordered plots (tori.gpi) run approx. 4 times faster than the hidden3d version (tori_hl.gpi). > If there really is a speed bottleneck in the code, I'd like > to try to pin it down and fix it. Then we can go back to > discussing if there are any other drawbacks to merging your > pm3d sort code with the general hidden3d capability. I believe that this is not a "bottleneck" but it is more the fact that it is really time consuming to do the correct hidden3d calculations. It think sorting the pm3d quadrangles and the hidden3d code are two very different approches: the hidden3d code has to calculate intersections of surfaces for example and doesn't draw hidden line segments at all. The pm3d code on the other hand draws all quadrangles: by sorting the quadrangles those lying in front overwrite those drawn before. It think the correct depth ordering for pm3d should be the default, since it is not really time consuming and it will most likely produce correct plots. The other pm3d methods (scans...) will produce likely incorrect plots (depending on your data for example). -- Johannes |
|
From: Johannes Z. <joh...@ze...> - 2005-11-20 19:49:25
|
On Sun, Nov 20, 2005 at 08:41:18PM +0100, Johannes Zellner wrote: > On Sun, Nov 20, 2005 at 10:58:48AM -0800, Ethan A Merritt wrote: > [...] > > Have you figured out any reason why the "set hidden3d" > > apparently runs much slower on your machines than on mine? > > The comparison depends pretty much on the sampling rate. Try to run the > attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my sorry, here are the attached test cases. -- Johannes |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-11-21 05:30:05
|
On Sunday 20 November 2005 11:41 am, Johannes Zellner wrote: > > The comparison depends pretty much on the sampling rate. Try to run the > attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my > machine the pm3d correctly ordered plots (tori.gpi) run approx. > 4 times faster than the hidden3d version (tori_hl.gpi). OK. Yes, I see the same difference in speed with isosamples set to 40. Although you can get a factor of roughly 4X back again by enabling HIDDEN3D_QUADTREE. > it is really time consuming to do the correct hidden3d calculations. > It think sorting the pm3d quadrangles and the hidden3d code are two very > different approches: the hidden3d code has to calculate intersections of > surfaces for example and doesn't draw hidden line segments at all. The > pm3d code on the other hand draws all quadrangles: by sorting the > quadrangles those lying in front overwrite those drawn before. > It think the correct depth ordering for pm3d should be the default, I agree with all of that. My question still remains, though: Why not move the Z-sorting of quadrangles into the hidden3d code? This will not magically do the full, correct, tests for which quadrangles to clip. But it *will* mean that other objects (labels, points, vectors) will be correctly obscured by the Z-sorted quadrangles, and vice versa. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-21 12:05:45
|
Ethan A Merritt wrote: > OK. Yes, I see the same difference in speed with isosamples set to 40. > Although you can get a factor of roughly 4X back again by enabling > HIDDEN3D_QUADTREE. At high isosamples settings, you should absolutely use that switch. I've even been thinking about enabling it by default. > This will not magically do the full, correct, tests for > which quadrangles to clip. But it *will* mean that other objects > (labels, points, vectors) will be correctly obscured by the > Z-sorted quadrangles, and vice versa. I'm reasonably sure it doesn't mean just that. It actually means means that all the problems inherent in treating polygons as sortable points will be inflicted on the hidden3d code's output. If you want other objects hidden-surface removed by the pm3d polygons, you can just feed those polygons to the hidden3d engine as they are, but flagged as invisible (like with the 'trianglepattern 0' option of 'set hidden3d'). The only real alternative would be to a full-featured, object-precision 3D rendering engine to replace both pm3d (polygons) and hidden3d (wireframe) output. Such a beast would probably be even slower than hidden3d already is. |
|
From: Petr M. <mi...@ph...> - 2005-11-23 23:44:26
|
>> OK. Yes, I see the same difference in speed with isosamples set to 40. >> Although you can get a factor of roughly 4X back again by enabling >> HIDDEN3D_QUADTREE. > > At high isosamples settings, you should absolutely use that switch. > I've even been thinking about enabling it by default. Unfortunately it is a compile-time switch. If it works, and gives good results, then make it as default. > The only real alternative would be to a full-featured, object-precision 3D > rendering engine to replace both pm3d (polygons) and hidden3d (wireframe) > output. Such a beast would probably be even slower than hidden3d already is. Do we really want (need) a full virtual reality engine in gnuplot? --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-21 12:14:41
|
Johannes Zellner wrote: > It think the correct depth ordering for pm3d should be the default, > since it is not really time consuming and it will most likely produce > correct plots. The other pm3d methods (scans...) will produce likely > incorrect plots (depending on your data for example). Not really. In what I expect to be the most frequent data patterns for pm3d plots (regular, x-y aligned grids of data), point-like depth-sorting will typically produce worse results than the currently existing output patterns. Scansbackward and Scansforward are not bad at all, for this kind of data. One of them will be exactly correct. To sum it up a little aggressively: z-sorting, scansbackward and scansforward are all about equally wrong, but are also each necessary to get a correct display in *some* case. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-11-24 00:04:26
|
> > > The only real alternative would be to a full-featured, object-precision 3D > > rendering engine to replace both pm3d (polygons) and hidden3d (wireframe) > > output. Such a beast would probably be even slower than hidden3d already is. > > Do we really want (need) a full virtual reality engine in gnuplot? What I want is the ability to mix surfaces, vectors, and labels in a single plot. I have not found an exact example yet, but maybe these give an idea of the desired output: http://www-space.eps.s.u-tokyo.ac.jp/~yokoyama/pub/gcn3d/ http://www.astro.ku.dk/~rmidjord/ComputerPhysics/Project2/3Drendering.jpg http://www.astro.phys.s.chiba-u.ac.jp/~matumoto/r-matsumoto.cdrom/d143bt68db.gif For this purpose I really am not worried about artifacts due to multiple overlapping surfaces or pathological topologies. I just want to hide the vectors and labels that are behind a colored surface while showing the ones in front. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2005-11-24 08:31:44
|
>> Do we really want (need) a full virtual reality engine in gnuplot? > > What I want is the ability to mix surfaces, vectors, and labels in a single plot. > I have not found an exact example yet, but maybe these give an idea of > the desired output: > > http://www-space.eps.s.u-tokyo.ac.jp/~yokoyama/pub/gcn3d/ > > For this purpose I really am not worried about artifacts due to > multiple overlapping surfaces or pathological topologies. I just want > to hide the vectors and labels that are behind a colored surface while > showing the ones in front. I see. I like this "simple depth" approach you are implementing. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-11-24 14:42:46
|
Petr Mikulik wrote: >>> enabling HIDDEN3D_QUADTREE. [...] > Unfortunately it is a compile-time switch. > If it works, and gives good results, then make it as default. I will. >> The only real alternative would be to a full-featured, >> object-precision 3D rendering engine to replace both pm3d (polygons) >> and hidden3d (wireframe) output. Such a beast would probably be even >> slower than hidden3d already is. > Do we really want (need) a full virtual reality engine in gnuplot? It doesn't have to be a VR engine (no interaction or real-time efficiency strictly needed), but yes, to resolve the problems inherent in the naive approach to 3D sorting currently being discussed for pm3d here, it would need to be quite a complete 3D engine. Worse yet, I don't think any such renderer exists yet --- pretty much nothing out there is done in object precision (i.e. returns results in terms of real drawable objects, not just coloured screen pixels), these days. Whether we *want* such a beast inside gnuplot, is the tricky question. Sorting pm3d polygons as if they're points will create nasty artifacts, and they'll be far from rare. As I said to Ethan before: if you you want to hide non-polygon stuff, hidden3d is the way to do it. |
|
From: V. <gae...@no...> - 2005-11-24 18:29:35
|
> >Do we really want (need) a full virtual reality engine in gnuplot?
> It doesn't have to be a VR engine (no interaction or real-time=20
> efficiency strictly needed), but yes, to resolve the problems inherent=20
> in the naive approach to 3D sorting currently being discussed for pm3d=20
> here, it would need to be quite a complete 3D engine.
Well, actually I had a close look at the 3D rendering code of
Gnuplot, and there is a certain amount of reorganising to be done,
especially moving the projection to separate function. I was planning to
try to do this but I am currently overwelmed with work, and it is likely
to go on. As far as rendering engines, I was thinking of povray and
opengl as rendering terminals.
--=20
Ga=EBl
|
|
From: Petr M. <mi...@ph...> - 2005-11-24 19:20:23
|
> As I said to Ethan before: if you you want to hide non-polygon stuff, > hidden3d is the way to do it. I think that even the "depth" z-ordering approach would be useful, and fast. --- Petr |
