qwtplot3d-interest

a few issues with qwtplot3d

[Gerard V. <ger...@gr...>]

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):
  part of the axes frame and the whole title do not show up, until I
  resize the simpleplot widget manually.  I am pretty sure that it is
  some initialization problem, because if I comment the statement
  plot.resize(800, 600) from main(), everything looks OK.
  (strange that the surface does not get chopped off).

- it took me some time to see that for you a tab means 2 spaces (all my tools
  on Linux interpret a tab as 8 spaces and display only 80 characters per
  line, so your code is pretty hard to read -- viewcvs also is confused:
http://cvs.sourceforge.net/viewcvs.py/qwtplot3d/qwtplot3d/include/qwt3d_plot.h?rev=1.17&view=auto )
  Uwe and I have the policy *not* to use tabs in Qwt (sometimes it happens,
  though).

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

- 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).

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.

Gerard

PS: OpenGL is new for me.  I am quite impressed with how snappy QwtPlot3D behaves
with respect to Vtk and its Python bindings.
    

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  
--