qwtplot3d-interest

Re: Continuation of "Drawing issues when updating in real-time"

[Vicente P. M. <vmi...@gm...>]

Hi Micha,

I use the Qthreads in my code.

I have trie to set a mutex for my slot, and it did not work. I have even set
it to some other parts that I thoght it could be the issue, but it did not
work either.

I also tried to change the connection type to Qt::BlockingQueuedConnection,
which does exactly the same job as a mutex, but no success =/.

That setTicLength part is all right, I mix X and Y due to the fact the tic
beeing set has the same orientation of the axis.
Anyway, just to make sure, I also tried to do setTicLenght(0, 0), but those
instant big tics still ocurred.

I think the problem must be with my VGA card, since you have exactly the
same configuration as me and do not get the same problem.

At least I can workround this situation by doing setFloorStyle(NOFLOOR).
I do not get to see the axis, which are not that important to my
application, but the plot gets more clean :).

Thank you very much for your effort Micha.
Any news regardint this problem, I will let you know.

Regards,

Vicente Peruffo Minotto

Re: Continuation of "Drawing issues when updating in real-time"

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

@Vicente

I cannot reproduce the behavior here. I have the very same system, 
except ATI replacing the NVIDIA card. But this shouldn't cause the 
problem, I think.

What kind of threading model is it, that is used in your code? Qt 
threads? I haven't to much experience with them, but could it be, that 
your slot misses some kind of Mutex, preventing paint events between 
updated scaling values but before new data are completely read. Or some 
similar inconsistency.

The things I mean, are mentioned here:

http://doc.trolltech.com/4.6/threads-qobject.html#accessing-qobject-subclasses-from-other-threads 
  etc.

How about serializing the code, what happens then?


A small issue:

Could it be, you mix X and Y in the following code sequence:

>     coords->axes[X1].setTicLength(3*yScale, yScale);
>     coords->axes[X2].setTicLength(3*yScale, yScale);
>     coords->axes[X3].setTicLength(3*yScale, yScale);
>     coords->axes[X4].setTicLength(3*yScale, yScale);
>
>     coords->axes[Y1].setTicLength(3*xScale, xScale);
>     coords->axes[Y2].setTicLength(3*xScale, xScale);
>     coords->axes[Y3].setTicLength(3*xScale, xScale);
>     coords->axes[Y4].setTicLength(3*xScale, xScale);

Micha

Continuation of "Drawing issues when updating in real-time"

[Vicente P. M. <vmi...@gm...>]

Hi Micha,

first of all, please ignore the last e-mail I sent to
kri...@us.... I thought you had not answered, but I
did not know the reply appeared only at the SF mailing list page. I thought
it would come to my mail box. Sorry about that :-(

Ok, so now for your question about my environment.

QwtPlot3D version: v0.2.7
OS: Windows 7 Profession x64
Qt version: 4.6.2
Compiler: Microsoft Visual Studio 2008 Professional
My GPU is a NVIDIA GeForce *GTS
360M*<http://www.notebookcheck.net/NVIDIA-GeForce-GTS-360M.24058.0.html>

All drivers, softwares, and libraries, that interfere in qwtplot3d's
compiling/running, are up-to-date (at least I think so :)).

Althought my OS is 64 bits, I have compiled all libraries I use in 32 bits
mode (MVS has a really easy way of doing that), including qwtplot3d and Qt
itself. I have done that in order to avoid incompatibility issues, and also
because qmake does not have a mkspec for x64 windows.

Any extra info you may need, pleast let me know.

Thank you for your effort in trying to help me!!

Best regards,

Vincent.

[qwtplot3d - General] RE: Drawing issues when updating in real-time

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

> I sent an e-mail to the list qwtplot3d-interest<at>  lists.sourceforge. net.
> I do not know if this address is still active? Is it?

Got it all. The address works and even the youtube link is valid. There 
was simply a weekend in between ;-)

BTW, could you provide some information regarding your environment 
(qwt3d (most important) and  Qt version, compiler, OS etc.)

Micha

Continuation of "Drawing issues when updating in real-time"

[Vicente P. M. <vmi...@gm...>]

Dear Micha,

as suggested, let us continue the conversation via this list.

Due to that mess in my posts, I do not know if you were able to see the link
to an youtube video I just uploaded. One that shows the proble ocurring.
Click here <http://www.youtube.com/watch?v=ut85B-w6iy4> if you have not seen
it yet.

I'll paste here again the codes I am using the update the 3D plot.

Note that below are posted 3 methods. One of them is the SLOT that is
responsible for the updating, which is the updt() method. The other two are
only methods I used to organize the code itself, which are called by the
updt() slot.

A signal is emmited to this slot about every 0.5 seconds after some real
hard processing done by the emmiting thread.

/*This method set all scaling parameters the will be used
to adjust the scales in the adjustScales() call.*/
void SurfacePlotter::setParameters(){
    FieldROI *roi = info->getFieldROI();

    numColumns = roi->getXNumPoints();
    numRows    = roi->getYNumPoints();
    xMin = roi->getXFirst();
    xMax = roi->getXLast();
    yMin = roi->getYFirst();
    yMax = roi->getYLast();
    zMax = info->getSpPeak();
    zMin = info->getSpMin();

    int xDelta = xMax - xMin;
    int yDelta = yMax - yMin;

    double xS, yS;

    if(xDelta > yDelta){
        xS = (double)xDelta / (double)yDelta;
        yS = 1.0;
    }
    else{
        yS = (double)yDelta / (double)xDelta;
        xS = 1.0;
    }

    xScale = xS*1./(xMax-xMin);
    yScale = yS*1./(yMax-yMin);
    zScale = 2./(zMax-zMin);

}

/*This method adjust all scales that are needed to plot a visually
correct 3D surface.*/
void SurfacePlotter::adjustScales(){
    ParallelEpiped hull = this->hull();

    d = (hull.maxVertex - hull.minVertex).length();

    setScale(xScale, yScale, zScale);

    setZoom(d / (2*sqrt(3.0)));

    coords->axes[Z1].setTicLength(3*xScale, xScale);
    coords->axes[Z2].setTicLength(3*xScale, xScale);
    coords->axes[Z3].setTicLength(3*xScale, xScale);
    coords->axes[Z4].setTicLength(3*xScale, xScale);

    coords->axes[X1].setTicLength(3*yScale, yScale);
    coords->axes[X2].setTicLength(3*yScale, yScale);
    coords->axes[X3].setTicLength(3*yScale, yScale);
    coords->axes[X4].setTicLength(3*yScale, yScale);

    coords->axes[Y1].setTicLength(3*xScale, xScale);
    coords->axes[Y2].setTicLength(3*xScale, xScale);
    coords->axes[Y3].setTicLength(3*xScale, xScale);
    coords->axes[Y4].setTicLength(3*xScale, xScale);

}

/*This method updates the 3D plot with new data regarding
the given instant of time. This is done by setting the scaling
parameters, loading the data, adjusting the scales, and drawing.*/
void SurfacePlotter::updt(ResultsInfo *info){

    this->info = info;
    this->setParameters();
    this->loadFromData(info->getSpPowers(), numColumns, numRows, xMin, xMax,
yMin, yMax);
    this->adjustScales();
    this->updateGL();
    saveLastImage();
}

If you need any extra part of my code, such as the thread that emmits the
signal, please let me know.

Thank you very much in advance.


-- 
Vicente Peruffo Minotto

Drag and Drop

[Robert B. <rob...@gm...>]

Has anyone successfully implemented drag and drop of data points using
Qwt3d.

Robert B

Bug in MeshPlot::createOpenGlData()

[Gernot K. <kl...@rt...>]

Hi Micha,

in MeshPlot::createOpenGlData() (module qwt3d_meshplot.cpp) is a bug.
When creating the polygons (i.e. inside of glBegin(GL_POLYGON)), the 
normal must be set before the vertex.
Swapping the line glNormal3d(...) (line# 269) with glVertex3d(...) 
(line# 268) solves it
(line numbers from SVN Revision 215).

Regards,
Gernot

Re: Qtiplot and qwtplot3d

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

Tuesday, May 12, 2009, 17:07:58, Gudjon I. Gudjonsson wrote:

>    I know you are very opposed to using statically linked libraries with
> Qtiplot but because of this unsolvable problem, would you be willing to
> sponsor Qtiplot with statically linked qwtplot3d libraries?

To support the approach - qwtplot3d's license is zlib (even for the new
versions). So, everyone can make it part of his source tree anyway. In
case, this doesn't collide with software quality policies (I know too
less regarding Debian here), that shouldn't constitute unresolvable
problems.

Micha  
-- 

Re: Release plans

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

> Source package:
>   qwtplot3d0 version 0.3.0~20090511svn including multiple_curves branch
> Binary packages:
>   libqwtplot3d0

Is this additional Zero enough? (sounds not too descriptive to me, but I
don't know anything about the subtleties of debian packaging).

> Is it OK that I release such a Debian package in order to release a new
> Qtiplot package even if you have not agreed on the final feature plan? I
> repeat that it takes more than a month to pass by the legal team and then

If the interface of the new version differs from this package, QtiPlot
breaks at the very same moment. Wouldn't it be possible to link the
special/hacked qwt3d variant exclusively with QtiPlot for the moment
(perhaps statically) and to release a fake package with the new name
(if necessary for the legalisation procedure - if not, there is no
reason to release anything empty, isn't it?).

Micha  
-- 

Re: Release plans

[Gudjon I. G. <gu...@mc...>]

Hi Micha

> The number will be 0.3.0, main reason is the switch to pure Qt4. If I
> understand it correctly, this formal issue (simple from a authors point)
> is a much more important part for package scheduling.
This sounds fine.
>
>> PyQwt3d, Labplot,
>> Scidavis and perhaps some more programs depend on 0.2.7.
>
> I'm not quite convinced from what I've seen from the current interface
> (not the functionality per se!) for multiple curves. I'll discuss this
> at least with John and Ion, so we can find solutions for a subset of the
> mentioned applications and the interface himself. I'm just in the
> process of preparing a proposal.
>
> I'm afraid, for others compatibility issues will occur (in any case, the
> interface *will* change) and they have to stay with 0.2.7 if untouched.
> (the things said still don't mean a complete overhaul). Regarding
> PyQwt3d, I'll try to contact Gerard.
The current status in Debian is the following.
Source package:
  qwtplot3d
Binary packages:
  libqwtplot3d-qt3
  libqwtplot3d-qt3-dev
  libqwtplot3d-qt4
  libqwtplot3d-qt4-dev
  libqwtplot3d-doc
In order to make all coexist, I had to add the ending
libqwtplot3d.so > libqwtplot3d-qt{3,4}.so
and
/usr/include/qwtplot3d > /usr/include/qwtplot3d-qt{3,4}

If version 0.3.0 only supports qt4, then I suggest the following plan for
my Debian package release.

Source package:
  qwtplot3d0 version 0.3.0~20090511svn including multiple_curves branch
Binary packages:
  libqwtplot3d0
  libqwtplot3d0-dev
  libqwtplot3d0-doc
and I don't change any library names or include directories. In that way,
both 0.2.7 and 0.3.0 can coexist and no one is forced to upgrade his
program until version 0.2.7 stops compiling.

Is it OK that I release such a Debian package in order to release a new
Qtiplot package even if you have not agreed on the final feature plan? I
repeat that it takes more than a month to pass by the legal team and then
I can just make an upgrade as soon as it enters Debian with your new
version, provided that the license doesn't change from the current one
(the current new one). A new package or new license means a lengthy pass
through the legal team.

Regards
Gudjon

Re: Spam handling (succeed?)

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

> The list is now private and most of the spam has been weeded out from
> the archive.

The list is public again (hard to subscribe in the 'private' case), but
posting ist allowed for members only now (didn't found the option at
first).

I hate that,
Micha  
-- 

Re: Release plans

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

Hi, Gudjon

> I was thinking about if the Qwtplot3d team had some kind of release plan.
> Currently there is an svn version in Debian 0.2.7+svn191 but I saw some
> activity in trunk, is there any 0.2.8 version upcoming?

The number will be 0.3.0, main reason is the switch to pure Qt4. If I
understand it correctly, this formal issue (simple from a authors point)
is a much more important part for package scheduling.

> PyQwt3d, Labplot,
> Scidavis and perhaps some more programs depend on 0.2.7.

I'm not quite convinced from what I've seen from the current interface
(not the functionality per se!) for multiple curves. I'll discuss this
at least with John and Ion, so we can find solutions for a subset of the
mentioned applications and the interface himself. I'm just in the
process of preparing a proposal.

I'm afraid, for others compatibility issues will occur (in any case, the
interface *will* change) and they have to stay with 0.2.7 if untouched.
(the things said still don't mean a complete overhaul). Regarding
PyQwt3d, I'll try to contact Gerard.

Is this something, you could live with for the moment, Gudjon?

Micha  
-- 

Re: Spam handling

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

The list is now private and most of the spam has been weeded out from
the archive.

Hope it helps,
Micha  
-- 

Re: Spam handling

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

> Can someone with access to the list remove these spammers?
> Please set up the list more restrictive to avoid this. 

Easier said than done. The list administrators (my) access is limited,
AFAICS. I could set some regular expression filters for the headers
manually. Of course, this wouldn't stop any real spam nowadays. It's
maybe a better idea, to use the forum exclusively or even one of the new
gadgets. http://apps.sourceforge.net/trac/sourceforge/wiki/Hosted%20Apps
lists some possibilities (phpBB?)

My mind is open :-)

Micha  
-- 

Release plans

[Gudjon I. G. <gu...@mc...>]

Hi

I was thinking about if the Qwtplot3d team had some kind of release plan.
Currently there is an svn version in Debian 0.2.7+svn191 but I saw some
activity in trunk, is there any 0.2.8 version upcoming? PyQwt3d, Labplot,
Scidavis and perhaps some more programs depend on 0.2.7.

I need to make a new version that supports Qtiplot but doesn't brake the
other programs. I guess that the code in trunk will be more or less
compatible with the current version. However I am thinking about making a
new package for the multiple_curves branch which is (will be) compatible
with Qtiplot and only support qt4, since I guess you won't support qt3 for
that branch.

Could you please put some informal plan on the qwtplot3d homepage on what
the future versions of qwtplot3d will be named and look like, it will make
my life as a packager much easier :) It takes more than a month to get a
new package (the multiple_curves branch) through the leagal team into
Debian but an upgrade takes no time. It is therefore important that I name
it correctly from the beginning.

Thanks
Gudjon

Re: Vector data - File output

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

> How about svg format - it is supported in Qt4.
> http://doc.trolltech.com/4.5/qtsvg.html

Qwt3d uses pure OpenGL for drawing, no combinations with Qt PaintEngine
(SVG in this case). For several reasons I would like to keep this design
decision. One of the consequences is, that any Vector drawing
functionality has to be duplicated (gl2ps does that "half-automatically"
by feeding output from OpenGL feedback buffer). No problem at all for
pixmaps as these are simply copies of the final framebuffer content.

> I realize this would break backward compatibility with 3.x, but maybe it is
> worth it?

We made a decision some time ago to break this (0.2.7 is still
available) and switch to pure Qt4. Anyone porting an application to Qt4
knows about the pain, and Qwt3d would little to nothing add to this :).
New developments will use Qt4 anyway.

Micha

Re: Vector data - File output

[Borries D. <de...@bi...>]

> 
> How important (who uses) the vector data formats (PDF,PS,EPS etc.) for
> file output with the library? These parts are increasingly hard to
> support and are a small PITA for some time to me anyway:
> - dependency of 3th party lib (even considered, that I wrote the PDF
>   part of gl2ps myself)
> - impossible to export all kind of OpenGL stuff
>   ( http://www.geuz.org/gl2ps/#tth_sEc5 )
>   This problem will worse with introducing more "modern" OpenGL.
> 
> Would you see problems in deprecating/skipping this part of the API?
>   
> Pixel formats are not affected.
> 
> Micha

How about svg format - it is supported in Qt4. 
http://doc.trolltech.com/4.5/qtsvg.html

I realize this would break backward compatibility with 3.x, but maybe it is 
worth it?

-borries

Vector data - File output

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

How important (who uses) the vector data formats (PDF,PS,EPS etc.) for
file output with the library? These parts are increasingly hard to
support and are a small PITA for some time to me anyway:
- dependency of 3th party lib (even considered, that I wrote the PDF
  part of gl2ps myself)
- impossible to export all kind of OpenGL stuff
  ( http://www.geuz.org/gl2ps/#tth_sEc5 )
  This problem will worse with introducing more "modern" OpenGL.

Would you see problems in deprecating/skipping this part of the API?
  
Pixel formats are not affected.

Micha
-- 

Re: Project status (to list and forum)

[John C. <jcu...@us...>]

Great! I'm still mired in conversion to Qt 4 and other projects that just seem 
to never quite get finished. QwtPlot3D definitely needs some attention once 
again. I would welcome you back!

-John

----------  Original Message  ----------

Subject: Project status (to list and forum)
Date: Wednesday 29 April 2009
From: Micha Bieber <kri...@us...>
To: "qwt...@li..." 
<qwt...@li...>

If nobody minds, I would make the following proposal. I left the project
around a year ago without plans to participate again. For several
reasons I would reanimate the poor thing:

- nostalgia
- it's a good project, I won't like seeing it dying entirely
- I have some fresh ideas (and some old ones coming back to my mind)
- I know a lot more about OpenGL now than some years ago and would like
implement some things (particularly shader based) with qwt3d as incarnation
and testbed

First steps would include the consolidation of a main version, including
the features from the different branches. This step should especially
reconcile maintainers (Gudjon :-). Step 2 includes some of the mentioned
older ideas/proposals (more rotation modes like arcball, picking, axis
descriptions).

Micha
-- 


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
qwtplot3d-interest mailing list
qwt...@li...
https://lists.sourceforge.net/lists/listinfo/qwtplot3d-interest

-------------------------------------------------------

Project status (to list and forum)

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

If nobody minds, I would make the following proposal. I left the project
around a year ago without plans to participate again. For several
reasons I would reanimate the poor thing:

- nostalgia
- it's a good project, I won't like seeing it dying entirely
- I have some fresh ideas (and some old ones coming back to my mind)
- I know a lot more about OpenGL now than some years ago and would like
implement some things (particularly shader based) with qwt3d as incarnation
and testbed

First steps would include the consolidation of a main version, including
the features from the different branches. This step should especially
reconcile maintainers (Gudjon :-). Step 2 includes some of the mentioned
older ideas/proposals (more rotation modes like arcball, picking, axis
descriptions).

Micha
-- 

Segmentation fault on Fedora 10

[Kincaid, L. <lw...@sa...>]

Hello-
I'm trying to debug a problem running qwtplot3d on Fedora 10.  I downloaded the source and am experimenting with two of the sample programs in the examples directory--mesh2 and simpleplot.  They compile and link just fine using Qt 3.3, but running the executable causes a segmentation fault.
This does not happen on Fedora 7.  Any suggestions would be appreciated.  Thanks.

Larry Kincaid
Sandia National Laboratories
lw...@sa...
(505) 845-0125 (office)

Fwd: [qwtplot3d - General] Rotation (and Translation and Scaling)

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

Hi all,

nice to hear about porting to Qt4. I would like bring an old message
from Todd Keith to your attention. Afterwards, Todd provided a patched
version of the then actual library (0.2.4 beta) to me. Are you still
interested in these features? Let me know if, and in this case how to
provide them (some tarball, zip or whatever to one of you might be the
simplest way).

Micha


===8<==============Original message text===============

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=2884389
By: takeith

FTF:  Excellent Library!  Thanks to the developer(s)!

Unless I missed something, rotation (and translation and scaling) in qwtplot3d
can currently only be done in model space, whereas it is often desirable to
do such transformations in view (screen) space, and also possibly using an arcball
rotation control.  For example, if I move the mouse along the X axis, I might
want the model to rotate around the screen y axis or translate along the screen
x-axis, not rotate around the the model Y axis or translate along the model
X axis.  Using quaternion-based transformation control, all of this can be achieved
cleanly and consistently.  I have modified qwtplot3d along these lines and would
be glad to have the changes incorporated into the qwtplot3d library ...

Also, I added the ability to select grid nodes / suface polygons, with the mouse
using OpenGL's selection mechanism and emit a signal indicating such a selection
has been made.  This may also be of general interest.

What is the preferred way for me to merge my changes into the official qwtplot3d
library, assuming of course you are interested?

Thanks again!
===8<===========End of original message text===========

qwtplot3d examples build problem

[<luk...@o2...>]

Hi,
I am using mingw32-make (GNU Make 3.81) on Windows XP sp2, to compile qwtplot3d (QT-4.4.0; qwt-5.1.1 ). Both Qt and qwt examples work OK. Qwtplot3d compiles OK. The problem occurs when I try to compile the qwtplot3d examples. Below is the compiler's output (an excerpt from examples compilation (with mingw32-make) verbose):

g++: /NODEFAULTLIB:msvcrt: No such file or directory
g++: ../../lib/qwtplot3d.lib: No such file or directory
mingw32-make[2]: *** [..\bin\simpleplot.exe] Error 1
mingw32-make[2]: Leaving directory `C:/DEVEL/qwtplot3d/examples/simpleplot'
mingw32-make[1]: *** [debug] Error 2
mingw32-make[1]: Leaving directory `C:/DEVEL/qwtplot3d/examples/simpleplot'
mingw32-make: *** [sub-simpleplot-make_default] Error 2

I am running out of solutions, Can anybody please give some hints on this?
Best, 
Lukasz

QwtPlot3D project Compilation with Code Blocks Fails

[<luk...@o2...>]

Hello, I am struggling with following problem:
I've built qwtplot3d with mingw32 (v.5.1.4) on my Windoze XP sp2. I am trying to run some examples project, but my IDE (CodeBlocks v. 8.02) returns the following compilation report:
/*******************************************************************************************/
Compiling: ..\..\Desktop\qwtplot3d\examples\autoswitch\autoswitchM.cpp
Compiling: ..\..\Desktop\qwtplot3d\examples\autoswitch\autoswitch.cpp
Linking executable: C:\Documents and Settings\Lukasz\Moje dokumenty\CppProjects\CodeBlocks\Diff3Dplot.exe
Info: resolving Qwt3D::SurfacePlot::staticMetaObject       by linking to __imp___ZN5Qwt3D11SurfacePlot16staticMetaObjectE (auto-import)
Info: resolving vtable for Qwt3D::Functionby linking to __imp___ZTVN5Qwt3D8FunctionE (auto-import)
.objs\Desktop\qwtplot3d\examples\autoswitch\autoswitch.o(.text$_ZN5Qwt3D8FunctionD2Ev[Qwt3D::Function::~Function()]+0xb):autoswitch.cpp: variable 'vtable for Qwt3D::Function' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 6 seconds)
0 errors, 0 warnings
/*******************************************************************************************/
I've created the moc file with qt's meta object tool, and added the output .cpp file to the project. 
The project is linked against the libs created during the qwtplot3d build process. 
Can Anybody help me with this issue?
Best,
Lukasz

Re: Several Bugs in 0.2.7 when compiling the examples

[Matthias P. <mat...@gm...>]

Matthias Pospiech schrieb:
> I experienced several problems with the project files in the example folder.
>
> I changed it in the following way to make it run with mingw
> win32{
>   LIBS += ../../lib/qwtplot3d.lib
>   #TEMPLATE  = vcapp
>   DEFINES  += QT_DLL QWT3D_DLL
>   RC_FILE = ../icon.rc
>   contains (CONFIG, debug)  {
>     #QMAKE_LFLAGS += /NODEFAULTLIB:msvcrt
>   }
> }
>
> but there is still a major poblem. The lib file "qwtplot3d.lib" is 
> simply not build by the main makefile.
> There is only a .a and .dll file. So what do I have to do to be able to 
> run make on the examples ?
>   
I now changed .lib to .dll, and it now compliled.

However I had to copy all resource files from qwtplot3d/examples to 
qwtplot3d/, because they were not found otherwise.

And worse and what I do not understand at all, make went through without 
any error. But besides some .o files in each /tmp folder there is no 
.exe in any of the examples!

Matthias