There were a couple of places where the configure scripts did not add
either includes to VTKm_INCLUDE_DIRS or libraries to VTKm_LIBRARIES.
The biggest offender was when the examples used find_package to load the
VTK-m configuration it needed. find_package cleared out the includes and
libraries, but it did not clear out the VTKm_<COMPONENT>_FOUND
variables. Normally, these variables would not be set before
find_package is called, but in this case the examples were called after
some partial configuration. I got around this issue by clearing out all
the *_FOUND variables in VTKmConfig.cmake.
The examples are now written so they can be copied out of the vtk-m
source and still build properly. This will help new users / developers
learn how to build projects that use VTK-m.
45ada6b5 Rework ArrayHandleCuda to make it stop generate warnings
4ca6ce2a nvcc doesn't have troubles with boost shared_ptr optimizations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !473
The GLEW library is optional, but without it you cannot do OpenGL
interop. The hello_world example uses OpenGL interop, but did not check
that GLEW was available. It tried to use GLEW and an error occured.
Consolidate background color in rendering classes
Before this commit, there were three separate classes (Mapper, Canvas,
and View) that were all managing their own version of the background
color. As you can imagine, this could easily become out of sync, and in
fact if the user code did not specify the same background at least
twice, it would not work.
Fix this by consolidating the background color management to the Canvas.
This is the class most responsible for maintaining the background. All
other classes get or set the background from the Canvas.
That said, I also removed setting the background color from the
constructor in the Canvas. This background color is overridden by the
View anyway, so having it there was only confusing.
See merge request !448
Before this commit, there were three separate classes (Mapper, Canvas,
and View) that were all managing their own version of the background
color. As you can imagine, this could easily become out of sync, and in
fact if the user code did not specify the same background at least
twice, it would not work.
Fix this by consolidating the background color management to the Canvas.
This is the class most responsible for maintaining the background. All
other classes get or set the background from the Canvas.
That said, I also removed setting the background color from the
constructor in the Canvas. This background color is overridden by the
View anyway, so having it there was only confusing.
It is now optional to give a Camera object when constructing a View. If
a Camera is not specified, one is automatically set up by calling
ResetToBounds on the spatial bounds of the scene.
This makes it even easier to set up a view.
Also implement pan and zoom for 2D cameras.
Update the rendering tests to do these camera rotations. This matches
better the viewpoint used before the previous camera changes.
Most of the time, you just match the WorldAnnotator with the canvas of
the same type. Rather than make the user specify it every time, add a
method to the canvas that creates a "good" WorldAnnotator to use with
it. Then, if a WorldAnnotator is not given to the View constructor, one
is automatically created from the Canvas.
The template parameters on vtkm::rendering::View are unnecessary. All
three of the templated classes are polymorphic (with virtual functions).
Thus, you just have to specify them at the constructor. Removing the
template parameters makes the syntax a bit cleaner and removes some
unnecessary duplication in the executable.
Removing the template does mean we cannot optimize in the future.
However, I expect us to start using more virtual methods rather than
less, so I think this is a move in the right direction.
With only a few exceptions for simple structures, we do not expose the
members of classes. Instead, we provide accessor methods. Do this for
Camera as well as add some helper methods.
The width and height are maintained out of necessity by the canvas. A
second copy was maintained by the camera, which was only used for
computing the aspect ratio and similar metrics for projections.
Having to maintain the width/height in two places is a bit of a hassle
and provides the opportunity for bugs if they get out of sync. Instead,
have the width/height managed in one place (the canvas) and pass them as
parameters as necessary.
Move some of the management of the width, height, and buffers to the base
Canvas class. Also, when it makes sense, get the width and height from
the rendering system.
Also changed the color buffer to be a Vec so that you don't have to
manage array offsets by hand.
All of these changes snowballed from the observation that the glut
example did not properly enable the depth buffer.
Generally we try not to expose the implementation details of how things
are stored in objects.
Also changed some arguments that should have been declared const to
actually be const.
Rename rendering classes
Per our discussion in our last technical meeting, we are renaming several
of the rendering classes to be more clear and consistent with other
software products.
See merge request !437
The word surface is more often used for something like a polygonal mesh,
so this name is quite confusing. Canvas is consistent with a
conventional name in GUI widget APIs.
The rendering classes do not actually manage windows, and window was not
descriptive of what this class was doing. We decided that the class was
mostly analogous to what we call a "view" in ParaView.
For header files, this only adds the file to IDE file lists, which is
convenient but not critical. However, the test did find a ligit error in
the hello_world example where the TBB build was actually using the
serial device adapter.
