Add glut rendering unittest.
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
See merge request !546
Make the GLFW package variables advanced, and add it to the configure components.
Modify the other examples that use GLUT to use the configure components command.
The UnitTestMapperGLFW test was coded to run in an interactive mode,
which was problematic when simply running the test. If no one was there
to exit the interactive window, the test would time out. This change
adds a "batch" mode that is on when run by ctest. The batch mode runs
through all configurations and exits.
The testing subdirectories were including the tests from the parent
directory. I believe this was a copy-paste error from the tests
originally all being in one file (where the unit_tests variable had all
tests appended) and then moved to subdirectories where they should not
be appended.
It is more common to use degrees when specifying a transform (thanks to
the classic OpenGL interface). Also, camera specifies the field of view in
degrees, which made rotations inconsistent. This change unifies all that.
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
In the previous commit, I removed the background color arguments from
all the constructors from the Canvas class. I had missed the fact that
this was used in UnitTestMapperOSMesa.
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.
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.
I do not have OSMesa on my main development platform, so I missed updating
some of the code when I changed the interface.
Also removed some inline statements on pure virtual functions that GCC
was complaining about.
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.
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.
There was an error in the CMakeLists.txt in the rendering tests where
the include directory was linked in instead of the OSMesa library.
It was a simple mistake of typing the wrong CMake variable.
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.
Specifically, I am trying to compile the code on OSX. OSX uses OpenGL
libraries in a different directory than most other installs (including
X11) and does not generally support GLX. These changes remove the files
that support GLX in systems that do not support it.
I also added several header files to the CMake lists that were not there
but should have been.
Several of the methods in View.h were giving me warnings about shadowed
variables because the name of the arguments were the same as some class
member variables. I fixed this by changing the variable names to match
the VTK-m coding convention of using capitalized words for class member
variables and starting lower case letter for method arguments and local
variables.
Since this ended up changing over half of the lines of View.h and
Camera.h anyway, I also made some other modifications to the style to put
it in alignment with VTK-m coding conventions including 2-space
indentation and more descriptive variable names.
