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