Menu
▾
▴
gnuplot-beta
|
From: KITA T. <t-...@cc...> - 2005-04-04 03:08:39
|
Hello, = I know I said 'in several weeks' but actually 'in several month,' I announce the first release of the patch to add povray and vrml terminals to gnuplot 4.0. http://t-kita.net/gnuplot_povrml/ # I would like to put the patch also in sourceforge.net as soon as # I get to know how. = These terminals have been mostly written by one of my students, = MIYATA Shigeo, and I have revised them against the errors and problems found while making the demo images. # In povray terminal, plotting with polygons is implemented thanks to # the suggestions from Harald Harders. The code is far from complete, but I would like to know how much gnuplot users are interested in these terminals. Any comments and suggestions will be appreciated. From: Ga=EBl Varoquaux Subject: Re: Now working on POV-Ray terminal Date: Fri, 4 Feb 2005 19:02:25 +0000 (UTC) > KITA Toshihiro <t-kita <at> cc.kumamoto-u.ac.jp> writes: > > Anyway, we would like to release the patch file as soon as possible= .= > > # to avoid excessive expectations. = > = > Anything that works is a starting point, and therefore a great prog= ress, I > find. It gives a basis to start building on. I am very much looking f= orward to > see your work. -- = KITA Toshihiro CMIT, Kumamoto University http://t-kita.net/ PGP-Key: http://t-kita.net/pubkey.asc fingerprint : CBFF 6A61 5990 10F5 B4B6 D2E8 279A 7063 CF8B 6339 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-04-04 04:19:25
|
On Sunday 03 April 2005 08:08 pm, KITA Toshihiro wrote: > http://t-kita.net/gnuplot_povrml/ I see you are post-processing to add transparency: set terminal povray set view 70,305 set out "tmp.pov" # klein.dat is one of the gnuplot demo data splot "klein.dat" with d set out ! sed 's/Red/Red filter 0.5/' tmp.pov > povray-demo3.pov ! povray +FC +A0.1 +I povray-demo3.pov Would it make sense to extend gnuplot's color specifications to include an alpha channel? I'm not so sure that's a good idea, actually. It might make sense, however, to have transparency be an attribute of each surface as a whole. Something like: plot "foo" with pm3d transparent, "baz" with pm3d solid -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-04-04 04:44:01
|
On Sunday 03 April 2005 08:08 pm, KITA Toshihiro wrote: > I announce the first release of the patch to add povray and vrml > terminals to gnuplot 4.0. > > http://t-kita.net/gnuplot_povrml/ > > Any comments and suggestions will be appreciated. The patch on your website is the patch you are talking about? It does not fit well with the design of gnuplot. Although you call these "terminals", in fact the terminal routines are just place holders, leaving the real work to be done by stand-alone routines that have to replicate all the data-handling and plot evaluation that the gnuplot core routines currently do. Such a design would be very hard to maintain, even if it were fully working. Every change to gnuplot's internal data structures or plotting capabilities would have to be made in parallel to the normal core routines and to these new povray and vrml routines. Therefore while this code is interesting as a proof-of-principle, I think that in order to progress towards inclusion into gnuplot proper all or most of this code must be moved into actual terminal driver routines (POVRAY_init(), POVRAY_options(), POVRAY_move(), etc). In the long run I think you will find that will be much simpler anyway. Let the existing core routines do the hard work for you. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: V. <gae...@en...> - 2005-04-04 23:24:11
|
Hello,
Great to see a gnuplot output some povray. It fantastic.
I gave it a quick look, but I won't have time to look at it again this
week.
#### My first impressions :
No colours, and color-box, that's really sad. I guess it is just a
matter of giving it a bit more work.
Titles should be reasonably easy to add.
set pm3d hidden3d doesn't seem to work.
The conventions you used to specify surface type are not quite
intuitive. There probably will be some thinking to do as to what gnuplot
instructions generate what povray material.
I suggest trying to stick as much as possible to gnuplot standard
behaviour :
*** No options -> wireframe + some thing like this :
pigment {
gradient z
color_map {
[0.0 color rgb <0,0,0>]
[0.25 color rgb <0.5,0,1>]
[0.5 color rgb <1,0,0>]
[0.75 color rgb <1,0.5,0>]
[1.0 color rgb <1,1,0>]
(of course the value of the colour map would be generated from the
gnuplot palette, possibly using gnuplot's "show palette palette <n>"
function)
*** set p3md transparent -> only wireframe (current default behaviour).
*** unset surface would turn the wireframe off.
#### A few comments on the code
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. I think it makes sens to separate 2D terminals (all
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.
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.
Thanks a lot for your and your student's work. I hope you will get
some help from people who know gnuplot's code better on this project. I
am willing to help (whenever I have time) with the terminal itself, but
I would rather not play with the core gnuplot function.
Ga=EBl
PS :
To answer ethan's suggestion about extending gnuplot's color
specifiaction to include alpha channel, yes, I think it would be great.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-04-05 16:46:12
|
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
|
|
From: Petr M. <mi...@ph...> - 2005-04-06 08:40:50
|
> 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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-04-06 14:35:01
|
>>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. |
|
From: V. <gae...@en...> - 2005-04-11 16:36:27
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-04-12 16:14:39
|
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
|
|
From: Petr M. <mi...@ph...> - 2005-04-12 17:04:34
|
> 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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-04-13 19:30:45
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-04-13 19:40:44
|
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. |
