Menu
▾
▴
gnuplot-beta
|
From: Johannes Z. <joh...@ze...> - 2004-12-02 17:27:23
|
Hello,
I just thought that coloring parametric surface plots according to the
computed z-Value is not reasonable or obvious at all. It would be
reasonable to color it according to any function which depends on u and
v (the parametric variables).
Thinking about the syntax, currently parametric surface plots expect
3 functions like
gnuplot> splot u, v, u*v
Would it make sense to allow a fourth /OPTIONAL/ function like (where
color(u, v) is any user-defined function which computes gray values):
gnuplot> set parametric
gnuplot> splot u, v, u*v, color(u, v) w pm3d
if pm3d is selected explicitely like above? I belive this wouldn't break
any existing scripts, would it?
On the other hand, to be consistent with non-parametric plots, one would
expect there the syntax
gnuplot> unset parametric
gnuplot> splot f(x, y), color(x, y) w pm3d
But this time, the specification is ambigous. It could mean:
1) plot f(x, y) and color the surface according to color(x, y)
2) plot f(x, y) and then plot a second surface color(x, y), which
is colored according to it's z-Value
Introducing an option which forces function plots to have a color
function would solve the ambiguity.
Or something like
gnuplot> set parametric
gnuplot> splot u, v, u*v w pm3d color(u, v)
And in the non-parametric case:
gnuplot> unset parametric
gnuplot> splot f(x, y) w pm3d color(x, y)
What do you think about this syntax?
Feedback is welcome!
--
Johannes
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-12-02 20:36:51
|
On Thursday 02 December 2004 09:27 am, Johannes Zellner wrote:
>
> I just thought that coloring parametric surface plots according to the
> computed z-Value is not reasonable or obvious at all.
I agree.
Then again, I have never needed to plot such a surface at all,
so maybe I am failing to imagine a reasonable use.
> It would be
> reasonable to color it according to any function which depends on u and
> v (the parametric variables).
Yes, that sounds much more reasonable. It gives you the same sort
of "4th dimension" that is available for plotting data from a file.
> gnuplot> unset parametric
> gnuplot> splot f(x, y), color(x, y) w pm3d
>
> But this time, the specification is ambigous.
I don't like the use of commas at all.
Any syntax that uses commas to mean more than one thing
is intrinsically ambiguous.
By analogy to the existing syntax for data files,
I think the above should instead be
gnuplot> splot using (x):(y):f(x,y):color(x,y)
which it may or may not be possible to shorten to
gnuplot> splot using f(x,y):color(x,y)
> Introducing an option which forces function plots to have a color
> function would solve the ambiguity.
To me it seems more logical to extend "using" to function plots,
and allow explicit assignment of either real or formal parameters
to the various columns. Since the syntax "splot using ..."
is not currently valid, it will not break existing scripts.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Johannes Z. <joh...@ze...> - 2004-12-03 15:22:48
|
On Thu, Dec 02, 2004 at 12:36:39PM -0800, Ethan Merritt wrote:
> On Thursday 02 December 2004 09:27 am, Johannes Zellner wrote:
> >
> > I just thought that coloring parametric surface plots according to the
> > computed z-Value is not reasonable or obvious at all.
>
> I agree.
> Then again, I have never needed to plot such a surface at all,
> so maybe I am failing to imagine a reasonable use.
>
> > It would be
> > reasonable to color it according to any function which depends on u and
> > v (the parametric variables).
>
> Yes, that sounds much more reasonable. It gives you the same sort
> of "4th dimension" that is available for plotting data from a file.
>
> > gnuplot> unset parametric
> > gnuplot> splot f(x, y), color(x, y) w pm3d
> >
> > But this time, the specification is ambigous.
>
> I don't like the use of commas at all.
> Any syntax that uses commas to mean more than one thing
> is intrinsically ambiguous.
> By analogy to the existing syntax for data files,
> I think the above should instead be
>
> gnuplot> splot using (x):(y):f(x,y):color(x,y)
>
> which it may or may not be possible to shorten to
>
> gnuplot> splot using f(x,y):color(x,y)
>
> > Introducing an option which forces function plots to have a color
> > function would solve the ambiguity.
and again what about:
gnuplot> splot u, v, u * v w pm3d [at s] [function color(u, v)]
the options after pm3d beeing optional? -- The [at s] option is already
present, so why not another option which specifies the color function?
This way it would be just like any style option, where you specify
options to "styles":
w lines lt 3 pt 1
w pm3d function color(u, v)
What's the difference, in principle?
HBB: would that overload the syntax too much?
And it would be backward compatible. And it's /EASY/ to implement (I'd
just a look ...)
--
Johannes
|
|
From: Petr M. <mi...@ph...> - 2004-12-06 17:48:27
|
(*) The ordering works with the torus example. But then I have tried this
demo:
set pm3d depth
splot 'whale.dat' with pm3d
but it does not do the ordering. What's wrong?
(*) The option "set pm3d ... depth" should have also "... nodepth" variant
to switch this feature off.
(*) Quadrangles may take a lot of memory. I propose to change double to
float (should probably happen also for gpdPoint structure).
typedef struct {
double gray;
double z; /* maximal z value after rotation to graph coordinate system
*/
gpdPoint corners[4];
gpiPoint icorners[4]; /* also if EXTENDED_COLOR_SPECS is not defined */
} quadrangle;
---
PM
|
|
From: Johannes Z. <joh...@ze...> - 2004-12-06 22:36:32
|
On Mon, Dec 06, 2004 at 06:48:16PM +0100, Petr Mikulik wrote:
> (*) The ordering works with the torus example. But then I have tried this
> demo:
>
> set pm3d depth
> splot 'whale.dat' with pm3d
actually here it works fine. I guess you're missing
set pm3d at s explicit
I guess I've to update the patch to work also with implicit surface
coloring.
--
Johannes
|
|
From: Petr M. <mi...@ph...> - 2004-12-07 08:37:26
|
> > set pm3d depth > > splot 'whale.dat' with pm3d > > actually here it works fine. I guess you're missing > > set pm3d at s explicit Yes, now it works fine. > I guess I've to update the patch to work also with implicit surface > coloring. That would be nice. --- PM |
|
From: Johannes Z. <joh...@ze...> - 2004-12-07 19:06:43
|
On Tue, Dec 07, 2004 at 09:35:35AM +0100, Petr Mikulik wrote:
> > > set pm3d depth
> > > splot 'whale.dat' with pm3d
> >
> > actually here it works fine. I guess you're missing
> >
> > set pm3d at s explicit
>
> Yes, now it works fine.
>
> > I guess I've to update the patch to work also with implicit surface
> > coloring.
>
> That would be nice.
I've just uploaded a patch to graph3d.c which implements the depth patch
also for "set pm3d implicit". Even if pm3d is "implicit", the surface
type has to be specified explicitely on the splot line like
gnuplot> set pm3d implicit
gnuplot> splot 'whale.dat' with pm3d
This is due to the fact that when using
gnuplot> set pm3d implicit
gnuplot> splot 'whale.dat'
the pm3d surface must be plotted before the default style (which might
be lines for example).
--
Johannes
|
|
From: Petr M. <mi...@ph...> - 2004-12-08 07:51:05
|
> I've just uploaded a patch to graph3d.c which implements the depth patch > also for "set pm3d implicit". Can you please upload the complete patch? pm3d.c fails to be patched. Thanks, Petr |
