gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Proposal to change behavior of "pause mouse key"

[Petr M. <mi...@ph...>]

> As I recall, Petr was the one who wanted "pause mouse key" to
> terminate on either mouse click or keystroke.  Is that still
> true?  Would it be OK to make this a separate option?

Yes, that's true -- I've just noticed that

2005-03-26
        * src/mouse.c (event_buttonpress) term/x11.trm (X11_waitforinput):
        Do not terminate "pause mouse key" on mouse button clicks. This allows
        zoom, select, and other mouse-click operations during the pause.

broke my app where it expects "pause mouse key" to terminate either on key,
or on mouse.

There is a bug:
   gnuplot> pause mouse hello
says "expecting string" but you have to recover by Ctrl/C or click.

>   pause mouse any
> 	terminates on either mouse click or keystroke (NEW)

Can you please add this variant? Thanks.


> Or maybe we should look ahead to other possible pause variants,
> and introduce new keywords, allowing multiple termination conditions:
>
>   pause mouse {key|button1|button2|...} "text prompt"
>
> Example:
>   pause mouse button1 key  "Hit any key or use left mouse button"

That could be useful too; maybe
    pause mouse button1,key
?


---
PM

"-persist"

[Massimo C. <me...@po...>]

Hi,
in gnuplot ver. 4 I used the option "-persist". This option was very 
useful to use gnuplot within a perl script.

In the version 4.1, it seems that this option is not still available.

Does it true or is there another command for the "persist" mode?

Thanks,
    Massimo.

P.S.: My perl script works in this way:
#!/usr/bin/perl

system("clear");

open(PLOTP, "|/usr/bin/gnuplot -persist") ||
                die "Couldn't run gnuplot: $!\n";

print PLOTP "set term postscript eps enhanced \"Times-Roman\" 14\n";
print PLOTP "set xlabel \"RR\"\n";
....

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please =?iso-8859-1?q?try=09POV-Ray_and_VRML_terminals?= )]

[Petr M. <mi...@ph...>]

> > set out "a.wrl"
> > !freewrl a.wrl
> > => and the OpenGL terminal is up and running without gnuplot's overhead.
>
> I assume you mean "If we had a working VRML driver, then..."

yes

> But in fact I did not have much luck with free-wrl when I last
> tried it.  The few VRML applications we have around here came
> out of the SGI world, and for whatever reason their output was
> not usable in free-wrl.  It may have been extended since then,
> of course.

Freewrl has well improved over the last 2 years, and the developer(s) are
well responsive to bug reports -- send them your files if not working.
Currently, freewrl works fine for me under Linux, and thus I haven't tried
openvrml for a long time.

---
PM

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please =?iso-8859-1?q?try=09POV-Ray_and_VRML_terminals?= )]

[Ethan M. <merritt@u.washington.edu>]

On Thursday 14 April 2005 06:39 am, Petr Mikulik wrote:
> 
> set out "a.wrl"
> !freewrl a.wrl
> => and the OpenGL terminal is up and running without gnuplot's overhead.

I assume you mean "If we had a working VRML driver, then..."

But in fact I did not have much luck with free-wrl when I last
tried it.  The few VRML applications we have around here came
out of the SGI world, and for whatever reason their output was
not usable in free-wrl.  It may have been extended since then,
of course.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[<br...@ph...>]

Ga=EBl Varoquaux wrote:

>   I was not aware of the term.c:do_arrow() and do_point(), I need t=
o
> spend more time reading gnuplot's code.=20

If you've ever done OO coding, it's quite simple: there'll be a "base=
=20
class" implementing a set of 3D terminal-like operations by,=20
essentially, calling map3d_xy() and then handing the work over to the
2D terminal API, or by calling other functions of the class.  Native =
3D
terminal drivers then get to "overload" as many of those methods as i=
t=20
takes to get the job done.


> Yes this is maybe a solution, but if you look at the way do_3dplot =
is
> currently written there is a lot of work to do to break it in
> routines that separate the data handling and resizing, from the
> projection and the removing of the hidden lines.

Of course.  The important thing to note is that collecting this code=
=20
into calls of native 3D terminal-style functions will benefit the=
=20
overall code quality even if we were to decide not to ever actually=
=20
incorporate 3D drivers.  We can only benefit from this, no matter how=
=20
far we actually go.

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please =?utf-8?q?try=09POV-Ray_and_VRML_terminals?= )]

[Petr M. <mi...@ph...>]

> Notwithstanding that, if people really want glossy 3D output images
> I offer a separate package that I have maintained for many years:
> 	http://www.bmsc.washington.edu/raster3d/raster3d.html
> Raster3D wasn't designed for this purpose, but then again neither was
> PovRay.  My package renders *much* faster than PovRay, because it
> "cheats" by using algorithms that are not truly ray-tracing.
> This is not much of a limitation unless you really need to model higher
> order properties like internal relection or refraction.
> On modern hardware it is very nearly fast enough to use as a
> software rendering engine for interactive use.  But not quite -
> a hardware-assisted OpenGL terminal would still be better for
> interaction, though not as good for final image quality.
> Raster3D also has the advantage that it is designed for use via a
> pipe, and writing a gnuplot terminal driver for it would be relatively
> simple (well, relative to PovRay anyhow :-).
>
> Please note that I'm not really pushing for development of a Raster3D
> terminal type, although I do think it would be more suited than PovRay.

I think gnuplot-3D should support output text files for:
- Povray
- Raster3D
- VRML


> To return to my original point, I think the driving force for revamping
> 3D plotting in gnuplot should be the creation of an interactive 3D
> terminal.  I would have thought OpenGL the obvious way to go, but
> VRML is also a possibility.

set out "a.wrl"
!freewrl a.wrl
=> and the OpenGL terminal is up and running without gnuplot's overhead.

FLTK or another 3D-capable terminal would be a major homework.

---
PM

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[V. <gae...@en...>]

On Wed, Apr 13, 2005 at 09:40:10PM +0200, Hans-Bernhard Broeker wrote:
> [Gael: please subscribe yourself to the mailing list --- it's getting=20
> cumbersome to manually approve each mail you send to it.]
  Done.


  Just to answer the discussion that has been going on in the "other"
threat" (that I have ne seen until today), I think that to add openGL
interactive terminal is a great idea, and I think it would be one of the
major benefits of having a proper 3D API, but such a terminal will not
allow to do "printouts", and povray seems well suited for that. Anyhow,
writing a povray terminal is rather easy (once the term3d api is done),
where as I have no clue how to handle openGL, and I therefore do not
know how hard writing a terminal that uses openGL would be.

  I must clarify my previous posts : when I was talking of "interface",
I always meant API and not user interface.

  I was not aware of the term.c:do_arrow() and do_point(), I need to
spend more time reading gnuplot's code. Yes this is maybe a solution,
but if you look at the way do_3dplot is currently written there is a lot
of work to do to break it in routines that separate the data handling
and resizing, from the projection and the removing of the hidden lines.

  For those do not know povray well, here is a brief description of what
can be done with it.

  Povray takes a 3D description of the scene, with camera and light. An
example of a povray file would be something like=20

#include "colors.inc"
camera {location <0,2,-3> look_at <0,1,0>}
light_source {<6,6,-2> color White}
plane {<0,1,0> pigment {color Yellow}
sphere {<0,1,0> pigment {color Red} finish {phong 1}}

  As you can see povray is preprocessed by CPP which allows to define
"Vector" macros, or a camera position defined by the same angles then
Gnuplot (povray can do math). Povray is like TeX, it is not interactive,
is only processes scenes and returns bitmap images.

--
  Ga=EBl

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please =?utf-8?q?try=09POV-Ray_and_VRML_terminals?= )]

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 12 April 2005 01:47 am, Justace Clutter wrote:

> So, you are wanting a more feature-full 3D interface, and 
> really it is the output that you are most interested in I am sure.  

No, I think you are wrong there.  I think the real interest in a true
3D interface should be that we can support interactive 3D plotting via
OpenGL, VRML, or other front-end terminal types.  The interactive mode
of splot is relatively primitive compared to a real 3D visualization
tool.  

Pretty 3D output imaging is a separate goal, and there are other paths 
available to reach it.

To me it seems that PovRay + gnuplot is not a good match.
It's a bad idea for the same reason that adding MSOffice-style
"3D bar charts" is a bad idea. The addition of full ray-tracing to the
kind of plots gnuplot makes would add "eye-candy", but would if anything
degrade the actual information content.

Notwithstanding that, if people really want glossy 3D output images
I offer a separate package that I have maintained for many years:
	http://www.bmsc.washington.edu/raster3d/raster3d.html
Raster3D wasn't designed for this purpose, but then again neither was
PovRay.  My package renders *much* faster than PovRay, because it
"cheats" by using algorithms that are not truly ray-tracing.
This is not much of a limitation unless you really need to model higher
order properties like internal relection or refraction.
On modern hardware it is very nearly fast enough to use as a 
software rendering engine for interactive use.  But not quite -
a hardware-assisted OpenGL terminal would still be better for
interaction, though not as good for final image quality.
Raster3D also has the advantage that it is designed for use via a
pipe, and writing a gnuplot terminal driver for it would be relatively
simple (well, relative to PovRay anyhow :-).

Please note that I'm not really pushing for development of a Raster3D 
terminal type, although I do think it would be more suited than PovRay.
To return to my original point, I think the driving force for revamping
3D plotting in gnuplot should be the creation of an interactive 3D
terminal.  I would have thought OpenGL the obvious way to go, but
VRML is also a possibility.

> PovRay is a well developed application that does its job very 
> well.

I agree. But its "job" is quite different from gnuplot's.
Let's get our job description drafted before we hire anyone :-)


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> On Monday 11 April 2005 09:35 am, Ga=EBl Varoquaux wrote:

[Gael: please subscribe yourself to the mailing list --- it's getting=20
cumbersome to manually approve each mail you send to it.]

>>  I think we should define a term3d api (the terminal code file .trm
>>could go in a separate directory, term3d for instance). It would
>>reproduce as much as possible the current terminal api, but in 3d
>>(positions would be given in 3d).

> Fine with me.

Dito.  We've discussed this before, and the conclusion back then was=20
similar: it'd sure make sense to do that, but at the time, nobody seemed =

in a position to actually tackle this project.

> I would prefer a different plan, that would in the end make the=20
> core code more readable.  Instead of adding lots of #ifdef....#endif
> blocks to the core routines, I'd rather create a new set of wrapper
> routines that can eventually handle both 2D and 3D terminals.

You wouldn't even necessarily have to create them --- they already=20
exist, as I pointed out earlier.  util3d.c is where the existing
routines are, and where new ones should start out.

Eventually, these routines should become the fall-back implementations=20
of the to-be-done terminal3D API, just like term.c:do_arrow() currently=20
implements arrow-drawing for all terminals that don't have their own=20
native arrows, and do_point() does the same for point symbols.

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 12 April 2005 10:04 am, Petr Mikulik wrote:
> > I would prefer a different plan, that would in the end make the
> > core code more readable.  Instead of adding lots of #ifdef....#endif
> > blocks to the core routines, I'd rather create a new set of wrapper
> > routines that can eventually handle both 2D and 3D terminals.
> 
> If there is plot_3D.c and graph_3D.c, there will not be so many additional
> defines.

True, but then we would have the inevitable problem of maintaining
two parallel versions of the core 3D plotting code: One version used
by true 3D terminals, and a a second version used by the existing
3D->projection->2D terminals.  I'd rather have a single set of 
core routines, and only distinguish by terminal type at a lower level.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[Petr M. <mi...@ph...>]

> plots*. So we are not really after a "more feature-full 3D", just a
> sensible way of making the existing 3D information available to a
> terminal (such as POV-Ray) that would have something useful to do with
> it.
>
> I'm assuming the POV-Ray driver needs 3D so that it can determine
> directions of shading and lighting, "ray trace" if you will?

I think the new "plot3d" will be "just" copying the complete 3D information
of all objects into the output 3D file in VRML, Povray,... syntax.

"set view" will be written as default Viewpoint (in VRML terminology), but
the user could rotate/zoom the scence by mouse in his favourite viewer.

> Unfortunately the existing 'API' doesn't allow for 3D.

That's rather good luck -- you can design it from scratch.

This proposal of new 3D plotting has nothing common with the current
(projected) flat 2D plotting. Or has it (except for reading data files)?

---
PM

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[Petr M. <mi...@ph...>]

> I would prefer a different plan, that would in the end make the
> core code more readable.  Instead of adding lots of #ifdef....#endif
> blocks to the core routines, I'd rather create a new set of wrapper
> routines that can eventually handle both 2D and 3D terminals.

If there is plot_3D.c and graph_3D.c, there will not be so many additional
defines.


---
PM

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[<dan...@ie...>]

> At the moment, the design of gnuplot assumes 2D output, and therefore
all the information passed to the terminals is just 2D, *even for 3D
plots*. So we are not really after a "more feature-full 3D", just a
sensible way of making the existing 3D information available to a
terminal (such as POV-Ray) that would have something useful to do with
it.

I'm assuming the POV-Ray driver needs 3D so that it can determine
directions of shading and lighting, "ray trace" if you will?  Is that
correct?  Or does POV-Ray also allow changing of viewing angle too?

Anyway, there is still (always?) work that could be done to clean up 3D
mode in gnuplot, i.e., to better organize the similar plot elements (colo=
r
boxes, keys, margins) and code progression between 2D and 3D.  If someone
wants to take on that project, that's fine with me.  But before doing
that, let me take out some of the #ifdef'd code for reading data into 2D
and 3D plots from a file... but I have little time to do that now.  (The
new method--now similar in 2D and 3D--has been in use by default for
probably 8+ months now, so I assume it is working fine.)

As far as the 3D POV-Ray, there is a routine something like "project3d"
(?) that maps points from 3D space to the 2D view.  Perhaps that could be
made to leave points as 3D or map to 2D based upon the ability of the
terminal to accept 3D data.  We're talking a major conceptual shift,
however.  Shaking the tree a bit too much probably, and difficult to work
in without coordinated effort when many developers are working on a
project.

Dan

Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[Ethan M. <merritt@u.washington.edu>]

On Monday 11 April 2005 09:35 am, Ga=EBl Varoquaux wrote:
>=20
>   I think we should define a term3d api (the terminal code file .trm
> could go in a separate directory, term3d for instance). It would
> reproduce as much as possible the current terminal api, but in 3d
> (positions would be given in 3d).

=46ine with me.

>   A flag could say weather the current terminal is 3d or not. In the
> different functions called by splot a switch could call the 3d
> function's when needed. Something like :
>=20
> #ifdef TERM3D
>     if (term_is_3d) {
>=20
>     }
>     else
>     {
> #endif=20
>=20
> #ifdef TERM3D
>     }
> #endif=20
>=20
>   The functions that will require modification are all that call
> map3d_xy and map3d_xyz, all that do direct calls to term->move
> term->vector (I am forgetting other evil 2d calls ?).

I would prefer a different plan, that would in the end make the=20
core code more readable.  Instead of adding lots of #ifdef....#endif
blocks to the core routines, I'd rather create a new set of wrapper
routines that can eventually handle both 2D and 3D terminals.
To begin with they need only handle the existing 2D terminals.
But as you extend the capabilities to 3D, you will only have to
make changes in a very small number of places (the wrapper routines)
rather than the 100s of call sites in the main code.

This approach worked very well for me when I added support for
string variables.  First I created a new routine try_to_get_string()
that at first simply duplicated the existing quoted-string parsing
code.  Then I replaced all the places in the core code that parsed
a string constant with a call to have the new routine do it for them.
When that was all working (still no new capabilities at that point),
I went ahead and change try_to_get_string() to handle string variables
as well as constants.  But this meant that I only had to change and
debug the new capability in a single routine, rather than at all the
original call sites.

So following this strategy, I would suggest to create for example
a new routine move_3d(double x, double y, double z)

Call sites in the core code such as the following:

        map3d_xy(points[i].x, points[i].y, points[i].z, &x0, &y0);
        clip_move(x0, y0);    /* eventually calls term->move(x0,y0) */

Would be replaced by

	move_3d(points[i].x, points[i].y, points[i].z);

And move_3d itself would look something like

#define TERM3D FALSE        /* will eventually be replaced by a real test! =
*/
move_3d( double x, double y, double z)
{
   unsigned int x0, y0;

   if (TERM3D) {
	/* 3D terminals not implemented yet */
   return;
   }

   /* The original 2D code */
   map3d_xy(x, y, z, &x0, &y0);
   clip_move(x0, y0);    /* eventually calls term->move(x0,y0) */

   return;
}


This approach makes the core code simpler rather than more
complicated, and much easier to read. =20

=46or other considerations (clipping and floating point coords),
please also see my earlier message in the POVRay/VRML thread. =20
=20
>   That's the current state of my projects. To implement those ideas I
> will need some support and guidance from a gnuplot developer. What do
> you think of this plan of action ? can you give me some support ? I will
> be very slow at working on this project : my work does not give me a lot
> of free time.
>=20
>   I must stress that I am totally unexperienced as far as working on a
> real project goes.

If you keep a reasonably up-to-date copy of your work in progress
on the SourceForge site as a patchset, then you will get feedback
from people as you go.  Try to make sure that each updated patchset
will build and run correctly, even if it doesn't do much else that is
new. For example, you might start by creating a new source file that
has primitives like the move_3d() routine I blocked out above.
Then you could switch over one or two call sites in the core routines
to use your new primitive, and modify the Makefile templates to include
your new files when gnuplot is built.  Let that be your starting
patchset, even though it does not add any new behaviour to the program
when it is running.  People can have a look at it and make suggestions
about coding style, implementation, and so on, while it is still in the
early stages of development.

However, the form for adding comments to the SourceForge patch site
is very awkward to use.  Discussion is much better carried out here
on the mailing list.=20

=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[Robert H. <en...@no...>]

> 	But you have mentioned a 3D interface?  What does that entail?  Just
> allowing options to current commands for 3D or a GUI?  I dont understand
> the extent of the interface?

Rereading the original messages, I can see the confusion, however I
suspect the word "interface" is being used to refer to the interface
between the core of gnuplot and the terminal drivers. These two parts
are conceptually separate, and have a well defined interface (or "API"
-- application program interface), which allows additional terminal
drivers to be easily written.

Unfortunately the existing 'API' doesn't allow for 3D.

Hope that clears it up.=20

> On Tue, 2005-04-12 at 14:57 +0100, Robert Hart wrote:
> > At the moment, the design of gnuplot assumes 2D output, and therefore
> > all the information passed to the terminals is just 2D, *even for 3D
> > plots*. So we are not really after a "more feature-full 3D", just a
> > sensible way of making the existing 3D information available to a
> > terminal (such as POV-Ray) that would have something useful to do with
> > it.
> >=20
> > Rob
> >=20
> > On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> > > Guess I should have sent this to the list (opps)
> > >=20
> > > Justace
> > >=20
> > > email message attachment, "Forwarded message - Re: Introducing real 3d
> > > in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )"
> > > On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> > > > Well,
> > > >=20
> > > > 	I did not read the earlier posts, but based on the subject before =
the
> > > > subject change I can get an idea.  If I got this wrong then I will =
run
> > > > to the corner...  |-).  So, you are wanting a more feature-full 3D
> > > > interface, and really it is the output that you are most interested=
 in I
> > > > am sure.  PovRay is a well developed application that does its job =
very
> > > > well.  To try to mimic the functionality of PovRay inside of gnuplot
> > > > would increase the complexity of the gnuplot code by an enormous am=
ount.
> > > > Now, gnuplot can already do 3d plots, with hidden line removal, and
> > > > tentative shading.  This can give you an idea where you can then mo=
ve
> > > > the plot over to povray.  Now as for the axes and the such, you wou=
ld
> > > > have to build that.=20=20
> > > > 	Trying to make a 3D interface does sound cool, but at what expense.
> > > > Why not make a povray terminal where the plot is rendered with povr=
ay
> > > > elements that can then be rendered, or manipulated by any povray ed=
itor
> > > > later.  To paraphrase a quote that I saw earlier...  Unix is an ide=
a, or
> > > > a style, where you create individually strong programs to work toge=
ther.
> > > > So, did I get this all wrong or am I on the right track.  If I did =
not
> > > > get this right, what true benefit would creating a 3D interface have
> > > > over using povray?
> > > >=20
> > > > Justace=20
> > > >=20
> > > > On Mon, 2005-04-11 at 18:35 +0200, Ga=EBl Varoquaux wrote:
> > > > >   I have had a good look at gnuplot's source code to try to figur=
e out
> > > > > what need to be done to build a 3d terminal interface.
> > > > >=20
> > > > >   My conclusion is that there is a quite large amount of work. As=
 I
> > > > > really would like this to happen I am ready to give it a try, eve=
n though
> > > > > this is way beyond any project I have ever tackled yet. I will of=
 course
> > > > > need some coaching in the process, as I am new to gnuplot's code =
and I do
> > > > > not know what is the development policy.
> > > > >=20
> > > > >   I think our first goal should be to build a working 3d interfac=
e, even
> > > > > if it does not implement all of gnuplot's possibility. Here are a=
 few
> > > > > random ideas I collected.=20
> > > > >=20
> > > > >   I think we should define a term3d api (the terminal code file .=
trm
> > > > > could go in a separate directory, term3d for instance). It would
> > > > > reproduce as much as possible the current terminal api, but in 3d
> > > > > (positions would be given in 3d).
> > > > >=20
> > > > >   The plotting code in gnuplot's main source file would have to be
> > > > > modified to use this api. As a temporary solution I suggested to =
tamper
> > > > > only with the code called by splot and leave plot out for 3d term=
inals
> > > > >=20
> > > > >   A flag could say weather the current terminal is 3d or not. In =
the
> > > > > different functions called by splot a switch could call the 3d
> > > > > function's when needed. Something like :
> > > > >=20
> > > > > #ifdef TERM3D
> > > > >     if (term_is_3d) {
> > > > >=20
> > > > >     }
> > > > >     else
> > > > >     {
> > > > > #endif=20
> > > > >=20
> > > > > #ifdef TERM3D
> > > > >     }
> > > > > #endif=20
> > > > >=20
> > > > >   The functions that will require modification are all that call
> > > > > map3d_xy and map3d_xyz, all that do direct calls to term->move
> > > > > term->vector (I am forgetting other evil 2d calls ?).
> > > > >=20
> > > > >=20
> > > > >   That's the current state of my projects. To implement those ide=
as I
> > > > > will need some support and guidance from a gnuplot developer. Wha=
t do
> > > > > you think of this plan of action ? can you give me some support ?=
 I will
> > > > > be very slow at working on this project : my work does not give m=
e a lot
> > > > > of free time.
> > > > >=20
> > > > >   I must stress that I am totally unexperienced as far as working=
 on a
> > > > > real project goes.
> > > > >=20
> > > > > --
> > > > >   Ga=EBl
> > > > >=20
> > > > >=20
> > > > > -------------------------------------------------------
> > > > > SF email is sponsored by - The IT Product Guide
> > > > > Read honest & candid reviews on hundreds of IT Products from real=
 users.
> > > > > Discover which products truly live up to the hype. Start reading =
now.
> > > > > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> > > > > _______________________________________________
> > > > > gnuplot-beta mailing list
> > > > > gnu...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > > >=20
>=20
>=20
--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[Justace C. <pro...@co...>]

Oh,

=09I guess that it make sense that the povray terminal, and other
terminals of that type should have all the 3d information.  Ok, so no=
w I
undertand, the 3D information should be propogated through and not
flattened.  I agree.  (although my agree does not mean much since I a=
m
not a developer)

=09But you have mentioned a 3D interface?  What does that entail?  Ju=
st
allowing options to current commands for 3D or a GUI?  I dont underst=
and
the extent of the interface?

Justace



On Tue, 2005-04-12 at 14:57 +0100, Robert Hart wrote:
> At the moment, the design of gnuplot assumes 2D output, and therefo=
re
> all the information passed to the terminals is just 2D, *even for 3=
D
> plots*. So we are not really after a "more feature-full 3D", just a
> sensible way of making the existing 3D information available to a
> terminal (such as POV-Ray) that would have something useful to do w=
ith
> it.
>=20
> Rob
>=20
> On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> > Guess I should have sent this to the list (opps)
> >=20
> > Justace
> >=20
> > email message attachment, "Forwarded message - Re: Introducing re=
al 3d
> > in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )"
> > On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> > > Well,
> > >=20
> > > =09I did not read the earlier posts, but based on the subject b=
efore the
> > > subject change I can get an idea.  If I got this wrong then I w=
ill run
> > > to the corner...  |-).  So, you are wanting a more feature-full=
 3D
> > > interface, and really it is the output that you are most intere=
sted in I
> > > am sure.  PovRay is a well developed application that does its =
job very
> > > well.  To try to mimic the functionality of PovRay inside of gn=
uplot
> > > would increase the complexity of the gnuplot code by an enormou=
s amount.
> > > Now, gnuplot can already do 3d plots, with hidden line removal,=
 and
> > > tentative shading.  This can give you an idea where you can the=
n move
> > > the plot over to povray.  Now as for the axes and the such, you=
 would
> > > have to build that. =20
> > > =09Trying to make a 3D interface does sound cool, but at what e=
xpense.
> > > Why not make a povray terminal where the plot is rendered with =
povray
> > > elements that can then be rendered, or manipulated by any povra=
y editor
> > > later.  To paraphrase a quote that I saw earlier...  Unix is an=
 idea, or
> > > a style, where you create individually strong programs to work =
together.
> > > So, did I get this all wrong or am I on the right track.  If I =
did not
> > > get this right, what true benefit would creating a 3D interface=
 have
> > > over using povray?
> > >=20
> > > Justace=20
> > >=20
> > > On Mon, 2005-04-11 at 18:35 +0200, Ga=EBl Varoquaux wrote:
> > > >   I have had a good look at gnuplot's source code to try to f=
igure out
> > > > what need to be done to build a 3d terminal interface.
> > > >=20
> > > >   My conclusion is that there is a quite large amount of work=
. As I
> > > > really would like this to happen I am ready to give it a try,=
 even though
> > > > this is way beyond any project I have ever tackled yet. I wil=
l of course
> > > > need some coaching in the process, as I am new to gnuplot's c=
ode and I do
> > > > not know what is the development policy.
> > > >=20
> > > >   I think our first goal should be to build a working 3d inte=
rface, even
> > > > if it does not implement all of gnuplot's possibility. Here a=
re a few
> > > > random ideas I collected.=20
> > > >=20
> > > >   I think we should define a term3d api (the terminal code fi=
le .trm
> > > > could go in a separate directory, term3d for instance). It wo=
uld
> > > > reproduce as much as possible the current terminal api, but i=
n 3d
> > > > (positions would be given in 3d).
> > > >=20
> > > >   The plotting code in gnuplot's main source file would have =
to be
> > > > modified to use this api. As a temporary solution I suggested=
 to tamper
> > > > only with the code called by splot and leave plot out for 3d =
terminals
> > > >=20
> > > >   A flag could say weather the current terminal is 3d or not.=
 In the
> > > > different functions called by splot a switch could call the 3=
d
> > > > function's when needed. Something like :
> > > >=20
> > > > #ifdef TERM3D
> > > >     if (term_is_3d) {
> > > >=20
> > > >     }
> > > >     else
> > > >     {
> > > > #endif=20
> > > >=20
> > > > #ifdef TERM3D
> > > >     }
> > > > #endif=20
> > > >=20
> > > >   The functions that will require modification are all that c=
all
> > > > map3d_xy and map3d_xyz, all that do direct calls to term->mov=
e
> > > > term->vector (I am forgetting other evil 2d calls ?).
> > > >=20
> > > >=20
> > > >   That's the current state of my projects. To implement those=
 ideas I
> > > > will need some support and guidance from a gnuplot developer.=
 What do
> > > > you think of this plan of action ? can you give me some suppo=
rt ? I will
> > > > be very slow at working on this project : my work does not gi=
ve me a lot
> > > > of free time.
> > > >=20
> > > >   I must stress that I am totally unexperienced as far as wor=
king on a
> > > > real project goes.
> > > >=20
> > > > --
> > > >   Ga=EBl
> > > >=20
> > > >=20
> > > > -------------------------------------------------------
> > > > SF email is sponsored by - The IT Product Guide
> > > > Read honest & candid reviews on hundreds of IT Products from =
real users.
> > > > Discover which products truly live up to the hype. Start read=
ing now.
> > > > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> > > > _______________________________________________
> > > > gnuplot-beta mailing list
> > > > gnu...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > >=20

Re: [Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[Robert H. <en...@no...>]

At the moment, the design of gnuplot assumes 2D output, and therefore
all the information passed to the terminals is just 2D, *even for 3D
plots*. So we are not really after a "more feature-full 3D", just a
sensible way of making the existing 3D information available to a
terminal (such as POV-Ray) that would have something useful to do with
it.

Rob

On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> Guess I should have sent this to the list (opps)
>=20
> Justace
>=20
> email message attachment, "Forwarded message - Re: Introducing real 3d
> in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )"
> On Tue, 2005-04-12 at 03:47 -0500, Justace Clutter wrote:
> > Well,
> >=20
> > 	I did not read the earlier posts, but based on the subject before the
> > subject change I can get an idea.  If I got this wrong then I will run
> > to the corner...  |-).  So, you are wanting a more feature-full 3D
> > interface, and really it is the output that you are most interested in I
> > am sure.  PovRay is a well developed application that does its job very
> > well.  To try to mimic the functionality of PovRay inside of gnuplot
> > would increase the complexity of the gnuplot code by an enormous amount.
> > Now, gnuplot can already do 3d plots, with hidden line removal, and
> > tentative shading.  This can give you an idea where you can then move
> > the plot over to povray.  Now as for the axes and the such, you would
> > have to build that.=20=20
> > 	Trying to make a 3D interface does sound cool, but at what expense.
> > Why not make a povray terminal where the plot is rendered with povray
> > elements that can then be rendered, or manipulated by any povray editor
> > later.  To paraphrase a quote that I saw earlier...  Unix is an idea, or
> > a style, where you create individually strong programs to work together.
> > So, did I get this all wrong or am I on the right track.  If I did not
> > get this right, what true benefit would creating a 3D interface have
> > over using povray?
> >=20
> > Justace=20
> >=20
> > On Mon, 2005-04-11 at 18:35 +0200, Ga=EBl Varoquaux wrote:
> > >   I have had a good look at gnuplot's source code to try to figure out
> > > what need to be done to build a 3d terminal interface.
> > >=20
> > >   My conclusion is that there is a quite large amount of work. As I
> > > really would like this to happen I am ready to give it a try, even th=
ough
> > > this is way beyond any project I have ever tackled yet. I will of cou=
rse
> > > need some coaching in the process, as I am new to gnuplot's code and =
I do
> > > not know what is the development policy.
> > >=20
> > >   I think our first goal should be to build a working 3d interface, e=
ven
> > > if it does not implement all of gnuplot's possibility. Here are a few
> > > random ideas I collected.=20
> > >=20
> > >   I think we should define a term3d api (the terminal code file .trm
> > > could go in a separate directory, term3d for instance). It would
> > > reproduce as much as possible the current terminal api, but in 3d
> > > (positions would be given in 3d).
> > >=20
> > >   The plotting code in gnuplot's main source file would have to be
> > > modified to use this api. As a temporary solution I suggested to tamp=
er
> > > only with the code called by splot and leave plot out for 3d terminals
> > >=20
> > >   A flag could say weather the current terminal is 3d or not. In the
> > > different functions called by splot a switch could call the 3d
> > > function's when needed. Something like :
> > >=20
> > > #ifdef TERM3D
> > >     if (term_is_3d) {
> > >=20
> > >     }
> > >     else
> > >     {
> > > #endif=20
> > >=20
> > > #ifdef TERM3D
> > >     }
> > > #endif=20
> > >=20
> > >   The functions that will require modification are all that call
> > > map3d_xy and map3d_xyz, all that do direct calls to term->move
> > > term->vector (I am forgetting other evil 2d calls ?).
> > >=20
> > >=20
> > >   That's the current state of my projects. To implement those ideas I
> > > will need some support and guidance from a gnuplot developer. What do
> > > you think of this plan of action ? can you give me some support ? I w=
ill
> > > be very slow at working on this project : my work does not give me a =
lot
> > > of free time.
> > >=20
> > >   I must stress that I am totally unexperienced as far as working on a
> > > real project goes.
> > >=20
> > > --
> > >   Ga=EBl
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > SF email is sponsored by - The IT Product Guide
> > > Read honest & candid reviews on hundreds of IT Products from real use=
rs.
> > > Discover which products truly live up to the hype. Start reading now.
> > > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=CCk
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >=20
--=20
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[Fwd: Re: Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )]

[Justace C. <pro...@co...>]

Guess I should have sent this to the list (opps)

Justace

Re: changing the color a curve in gnuplot

[<br...@ph...>]

Gedeon Legaut wrote:
> gnuplot
>  > plot sin(x)
> plots a red curve. How can I get a blue curve instead of a red one ?

[Please have at least one look into documentation and FAQ before posting 
to the mailing list, and consider the users' list or newsgroup before 
you bother the developers, in the future...]

	plot sin(x) linetype 3

on some terminals.  See "help test" for how find out the correct number
for your terminal driver.

changing the color a curve in gnuplot

[Gedeon L. <Ged...@ob...>]

gnuplot
 > plot sin(x)
plots a red curve. How can I get a blue curve instead of a red one ?
thanks a lot
Ged

Introducing real 3d in Gnuplot (Was: Re: please try POV-Ray and VRML terminals )

[V. <gae...@en...>]

  I have had a good look at gnuplot's source code to try to figure out
what need to be done to build a 3d terminal interface.

  My conclusion is that there is a quite large amount of work. As I
really would like this to happen I am ready to give it a try, even though
this is way beyond any project I have ever tackled yet. I will of course
need some coaching in the process, as I am new to gnuplot's code and I do
not know what is the development policy.

  I think our first goal should be to build a working 3d interface, even
if it does not implement all of gnuplot's possibility. Here are a few
random ideas I collected.=20

  I think we should define a term3d api (the terminal code file .trm
could go in a separate directory, term3d for instance). It would
reproduce as much as possible the current terminal api, but in 3d
(positions would be given in 3d).

  The plotting code in gnuplot's main source file would have to be
modified to use this api. As a temporary solution I suggested to tamper
only with the code called by splot and leave plot out for 3d terminals

  A flag could say weather the current terminal is 3d or not. In the
different functions called by splot a switch could call the 3d
function's when needed. Something like :

#ifdef TERM3D
    if (term_is_3d) {

    }
    else
    {
#endif=20

#ifdef TERM3D
    }
#endif=20

  The functions that will require modification are all that call
map3d_xy and map3d_xyz, all that do direct calls to term->move
term->vector (I am forgetting other evil 2d calls ?).


  That's the current state of my projects. To implement those ideas I
will need some support and guidance from a gnuplot developer. What do
you think of this plan of action ? can you give me some support ? I will
be very slow at working on this project : my work does not give me a lot
of free time.

  I must stress that I am totally unexperienced as far as working on a
real project goes.

--
  Ga=EBl

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

[Hans-Bernhard B. <br...@ph...>]

>>After a quick look at what would be needed, I think you could start out
>>by adding only 2 new terminal API definitions
>>	term->move3d(double x, double y, double z);
>>	term->vector3d(double x, double y, double z);

That really wouldn't get us anywhere.  If 3D support is going to be 
usable, we'll need essentially all functions that currently take
(x,y) argument pairs in 3D versions.  Besides, move() and vector(),
those would be: put_text, point, arrow, fillbox, set_ruler, set_cursor,
filled_polygon, image.

Actually I doubt there's much sense in mounting the envisioned 3D
terminal API on top of the existing one.  A new, separate 'term3d'
construction would most likely be preferrable.

> The terminal should have a "IS3D" flag.

I don't see how that would help us.

> Another working scheme, instead of flooding all 2D terminals with dummy 3D
> routines, 

No such flooding needed --- that's what we have the automatic TERMENTRY
fill-up and the compiler's zero-initialization for.

Indeed, the best way of doing this is probably to move some of the 
routines currently in util3d.c into a new term3d.c, and make those 
become the "base class" for all 3D drawing.  If the terminal driver in 
use is a 2D-only one, they would fall back doing what gnuplot currently 
does.

Indeed util3d.c already is effectively providing a 3D drawing API for 
the rest of gnuplot right now.  E.g if you go looking for calls to 
term->move and term->vector, you'll find that there are only a few calls 
to these directly from *3d.c modules (7 out of 111, and
9 out of 185, respectively).  All the rest goes through draw3d_line(), 
polyline3d_*(), clip_move()/clip_vector() and similar helper functions.

Yes, it would be a big effort to reorganize this to feed all the data 
through proper 3D functions.  But besides gaining the
ability of implementing 3D terminal drivers more cleanly, it'd also
make the existing code easier.  The goal would be to remove map3d_xy()
from almost everywhere but the fall-back implementations of 3D terminal
API functions like term3d->move().  Currently, map3d_xy() is called 44 
times in the source, from various modules, for various purposes.

> Can those term->do3d() have variable argument list?

They can, but I really don't see a significant improvement over
having several independent terminal entries.  A single dummy is not 
significantly easier to put into drivers than ten dummies.

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

[Petr M. <mi...@ph...>]

> After a quick look at what would be needed, I think you could start out
> by adding only 2 new terminal API definitions
> 	term->move3d(double x, double y, double z);
> 	term->vector3d(double x, double y, double z);
>
> Two more that might or might not be needed
> 	term->point3d();
> 	term->put_text3d();
> These latter two could maybe be omitted if 3D terminals used a convention
> that you must do an explicit move prior to writing a point or a text string.
>
> The most interesting 3D drawing element, term->filled_polygon(),
> already passes a structure pointer rather than in-line coordinates.

The terminal should have a "IS3D" flag.

Another working scheme, instead of flooding all 2D terminals with dummy 3D
routines, is a single generic API
  term->do3d(XX3D_MOVE, param1, param2)
  term->do3d(XX3D_VECTOR, param1, param2, param3)
  term->do3d(XX3D_POINT, param1, param2, param3)
  term->do3d(XX3D_OPACITY, param1, param2, param3)
  term->do3d(XX3D_LIGHT, param1)
  term->do3d(XX3D_SKY, param1)
etc.
Can those term->do3d() have variable argument list?
If not, do3d_1param, do3d_2params, do3d_3params.

---
PM

Re: please try POV-Ray and VRML terminals (Re: Now working on POV-Ray terminal)

[Ethan M. <merritt@u.washington.edu>]

On Monday 04 April 2005 04:22 pm, Ga=EBl Varoquaux wrote:

> #### A few comments on the code
>=20
>   Looking at gnuplot's code and at the way you patched gnuplot to have
> the povray terminal work, this patch seems a bit of a dirty hack. It
> establishes special routines to plot vrml and povray. As Ethan points
> out this will probably be very hard to maintain. The file=20
> gnuplot-4.0.0/term/README defines quite clearly the way it shoud be
> done. However in a povray or vrml terminal, this terminal standard
> cannot be defined.=20

Cannot be defined?  I don't understand what you mean.

> I think it makes sens to separate 2D terminals (all=20
> existing ones) and 3D terminals (vrml, povray, and hopefully more). The
> core gnuplot core could be adapted to behave differently whether the
> terminal is 2D or 3D (is is currently a completely 2D code) and the
> actual translation of gnuplot internals in povray code could be made by
> the terminal.

While there may be a conceptual difference between 2D and 3D terminals,
I do not think that it will make a large difference to the terminal code.
A larger issue may be whether coordinates must be given as floats rather
than the (unsigned int) values used by the current terminal API routines.
I'll assume we can move to floats for 3D operations.

After a quick look at what would be needed, I think you could start out
by adding only 2 new terminal API definitions
	term->move3d(double x, double y, double z);
	term->vector3d(double x, double y, double z);

Two more that might or might not be needed
	term->point3d();
	term->put_text3d();
These latter two could maybe be omitted if 3D terminals used a convention
that you must do an explicit move prior to writing a point or a text string.

The most interesting 3D drawing element, term->filled_polygon(),=20
already passes a structure pointer rather than in-line coordinates.
So I think this call format can be used by either 2D or 3D code.=20

>   Of course setting up the 3D code in gnuplot would require some work
> from gnuplot devellopers, but I think it is worth the while. Especially
> since the 2D code could be a projection of the 3D code. But I haven't
> looked enough at gnuplots internal to know if this is possible.

That's pretty much what it does now.=20
=46or example, there are many code fragments in graph3d.c of the form

	map3d_xy(points[i].x, points[i].y, points[i].z, &x0, &y0);
	map3d_xy(points[j].x, points[j].y, points[j].z, &x, &y);=09
	clip_move(x0, y0);    /* eventually calls term->move(x0,y0) */
	clip_vector(x, y);    /* eventually calls term->vector(x,y) */

To handle true 3D terminals this would become

	if (term->move3d) {
	    term->move3d(points[i].x, points[i].y, points[i].z);
	    term->vector3d(points[j].x, points[j].y, points[j].z);
	} else {
	    /* existing 2D code */
	}

Yes, this would affect a *lot* of places in the code.
But it is relatively straightforward, and it has minimal impact on
the existing terminal API. As I say, the biggest headache is probably
not having to skip the 3D->2D projection, but rather the desire to pass
floating point coordinates to the drivers.

Some things that should be decided before plunging in to
coding:

1) How to handle clipping (if at all)

2) How to handle 2D plots (fixed Z coordinate? don't allow?)

3) Should gnuplot try to create self-contained povray/vrml files,
   or should it settle for creating chunks that must be embedded
   in a wrapper file (like the LaTeX terminal types)

4) What other 3D output formats are of interest, and does this
   approach allow for them to be added later.  In particular,
   what are the chances that an interactive OpenGL terminal
   implementation would be compatible with this approach.
=20
> PS :
>   To answer ethan's suggestion about extending gnuplot's color
> specifiaction to include alpha channel, yes, I think it would be great.

But in my experience you normally want a property like transparency
to apply to an entire surface.  I suspect it is more convenient to
set this more globally rather than having to include it in every call
that includes a color spec.  By the way, the png/jpeg/gif terminal
and the svg terminal would be able to use transparency also,
so this is really a separate discussion from 3D extensions.


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Helpe! More Colors in gnuplot

[Ragner <rag...@gm...>]

How do I plot 

splot "freq.0" with boxes 1,\
"freq.1" with boxes 2, \
"freq.10" with boxes 3, \
"freq.11" with boxes 4, \
"freq.12" with boxes 5, \
"freq.13" with boxes 6, \
"freq.14" with boxes 7, \
"freq.15" with boxes 8, \
"freq.16" with boxes 9, \
"freq.17" with boxes 10, \
"freq.18" with boxes 11, \
"freq.19" with boxes 12, \
"freq.2" with boxes 13, \
"freq.20" with boxes 14, \
"freq.3" with boxes 15, \
"freq.4" with boxes 16, \
"freq.5" with boxes 17, \
"freq.6" with boxes 18, \
"freq.7" with boxes 19, \
"freq.8" with boxes 20, \
"freq.9" with boxes 21

with diffirent colors for each  data (freq.1,freq.2, ..., freq.20, freq.21)

Exemple data in  file  freq.*

95.2 98 0
96.28 70 2
98.28 80 0
99.28 90 3



-- 
Felizes os que confiam no Senhor !