|
From: Hans-Bernhard B. <br...@ph...> - 2004-12-02 20:44:51
|
On Thu, 2 Dec 2004, 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. Oh, Johannes is just setting out on a mission to beat Mathematica in the game of "making glorious pictures of maths". No big deal, piece of cake actually ;-> > > 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) Good thinging, in principle. Except > Since the syntax "splot using ..." is not currently valid, it will not > break existing scripts. may not be 100% correct. Some daring young fella *might* have gone ahead and defined himself a function named 'using' ;-) -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-12-06 20:57:55
|
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
>
> but it does not do the ordering. What's wrong?
Probably that Johannes didn't think about multi-mesh and multi-function
plots. Hidden surface removal can't really be done on individual
surfaces --- you *have* to do it for the entire display. There's a
reason 'set hidden3d' is a global setting, and its implementation
intermixed all through the 3D graphics output routines.
Which brings me to a suggestion: this new depth-sorting feature may have
to be re-organized from scratch, and moved to be controlled by 'set
hidden3d'. I.e. it'll become the hidden3d mode of pm3d (rather than
what currently sails under than option name in 'set pm3d', which is
something entirely different).
> (*) The option "set pm3d ... depth" should have also "... nodepth" variant
> to switch this feature off.
From what I understood, 'depthsorting' is an exclusive alternative to
'scans{forward|backward|default}', so wouldn't 'scansdefault' do that
already?
> (*) 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;
Please, if you do that, respect prior art and use the existing type
'coordval' for that. That's what this type was designed for: it's
defined as double on platforms that can afford it, and float elsewhere.
|
|
From: Petr M. <mi...@ph...> - 2004-12-07 08:57:31
|
> > (*) 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;
>
> Please, if you do that, respect prior art and use the existing type
> 'coordval' for that. That's what this type was designed for: it's
> defined as double on platforms that can afford it, and float elsewhere.
IMHO, gnuplot is using too much memory for images and surfaces -- or, in
other words, it can work with large images, like >=512^2 pts, but it
suffers. I would prefer not to use double if float is sufficient, as in this
case.
The above structure is 64 B for double, and 40 B for float.
For an image of 512^2 it would save 6 MB.
Well, we can always recompile gnuplot for using float instead of double. I
do sometimes.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-12-02 21:38:25
|
On Thursday 02 December 2004 12:44 pm, Hans-Bernhard Broeker wrote: > > gnuplot> splot using (x):(y):f(x,y):color(x,y) > > > it will not break existing scripts. > > may not be 100% correct. Some daring young fella *might* have gone ahead > and defined himself a function named 'using' ;-) Good point ;-) More likely, though, he tried to 'splot u(x)' which could still run aground on the obvious implementation if almost_equals(c_token, "u$sing") So there is a real concern hiding in there. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |