Re: a few issues with qwtplot3d

[Micha B. <kri...@us...>]

Sunday, November 14, 2004, 17:29:33, Gerard Vermeulen wrote:

> Hi Micha,

> In the process of making Python bindings for QwtPlot3D, I have found the
> following (minor) problems:

> - your simpleplot program has a problem (which may only show up on X):

not generally - in fact, I never recognized this on any Linux system.

>   Uwe and I have the policy *not* to use tabs in Qwt (sometimes it happens,
>   though).

I agree, I think I 'll change it step by step in the CVS.

> - SurfacePlot::createNormals() is declared in the headers, but not defined.

Ooops ..

> - I do not like your definition of DataRows which leads to a lot of
>   allocations or double[3].  I would define DataRow as:
>   typedef DataRow std::vector<Triple>;

>   and abuse the fact that sizeof(Triple) == sizeof(double[3]).
>   IMO, it is not only more efficient but would also lead to cleaner code
>   in qwt3d_gridplot.cpp (if you like, I can send a patch).
>   (I am aware that GL vertices can be triplets or quadruplets, but that
>    is maybe something for the future).

I see the point. For this and similar reasons the internal data
structure is not public. This gives me the opportunity to change the
structure, if I need so. E.g., I was not sure in the beginning, if the
Triple struct needs additional features (your sizeof argument becomes false in
this case and it is so possibly also for the existing variant). BTW, I
still play with transparent surfaces and need the 4th argument for this.

> Just a few other ideas, since my problem of 3D plots on a 2D screen is that I cannot read
> off coordinates of a point on a surface:
> - Would it be possible to implement some cursor which moves on the surface (ctrl-x or ctrl-y
>   for positive x or y direction and alt-x or alt-y for negative x or y direction)?
> - Another type of "cursor" would be a plane parallel to the z-direction which cuts the
>   surface. The plane can have a direction parallel to any vector in the x-y plane and
>   have an offset with respect to the origin of the axes.

In fact, I had an implementation like this in a very early version of
qwtplot3d. Here, transparency came into the game (for the cutting plane
and also the respective data on every side of the plane). Also it is not
nailed down forever, that I will interpolate exclusively linearly
between data points. Which data values should the cursor return, if I
choose e.g a (nonlinear) spline interpolation? Eventually he has to be a
bit more intelligent resp. I have to give him some sort of information to
take with them. Finally - and most important - it is a design decision.
I always look for solutions to keep the widget free from too special
features (related also to your 'snappy' argument in the post scriptum
and a relatively small API in general). But I tend to agree, that
cutting planes qualify for more general support and I will see what I
can do here.

Micha  
--