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.