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