Loosen threshold on test of parametric coordinates
The UnitTestParametricCoordinates test uses a pseudorandom number
generator to create some random set of parametric coordinates, convert
to world coordinates, and then back to parametric coordinates.
This has been working fine except that the world coordinate to parametric
coordinate conversion is not extremely precise for some cell shapes. (It
would not be cost effective to make it more precise.) Because of this,
the test_equal for this comparison has a pretty high threshold.
While looking at a dashboard I happened across a failure for this test.
It turns out that one of the parametric coordinates created for the
pyramid test for seed 1465529014 was just outside of this threshold, but
otherwise correct. I raised the threshold a little to try to prevent
this error.
See merge request !449
C has a feature where if you perform arithmetic on small integers (like
char and short), it will automatically promote the result to a 32 bit
integer. If you then store that back in the same type you started with
GCC will warn you that you are loosing the precision (that you didn't ask
for in the first place). This is particularly annoying in templated
code.
Anyway, fixed yet another instance of that happening.
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.
The UnitTestParametricCoordinates test uses a pseudorandom number
generator to create some random set of parametric coordinates, convert
to world coordinates, and then back to parametric coordinates.
This has been working fine except that the world coordinate to parametric
coordinate conversion is not extremely precise for some cell shapes. (It
would not be cost effective to make it more precise.) Because of this,
the test_equal for this comparison has a pretty high threshold.
While looking at a dashboard I happened across a failure for this test.
It turns out that one of the parametric coordinates created for the
pyramid test for seed 1465529014 was just outside of this threshold, but
otherwise correct. I raised the threshold a little to try to prevent
this error.
The new implementation assumes that the fourth component of the
homogeneous coordinate is not changed, which is true for all common
transforms except perspective projections. This should save several math
instructions to compute the fourth component and then divide the others
by it. If needed we can make a second method that does the complete
transform.
I am hoping that this will also solve what appears to be an optimization
bug on one of the dashboards.
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.
Affine transformations of homogeneous coordinates using 4x4 matrices are
quite common in visualization. Create a new math header file in the base
vtkm namespace that has common functions for such coordinates.
Much of this implementation was taken from the rendering matrix helpers.
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.
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.
The SamplerRect worklet had an error where it was possible that the
invSpacing stack-local values could be used uninitialized. On the first
iteration of the loop in the SamplerRect operation, it calls LocateCell,
which is supposed to set invSpacing. Under most conditions it does, but
if one of the ray directions is 0 (which can happen with axis-aligned
views), one of the invSpacing dimensions was skipped, leaving the value
to whatever garbage happened to be on the stack. Later, the invSpacing
value was used to interpolate a scalar, which under some circumstances
could cause an array index error when looking up a color in the color
map.
This fix changes the condition for when the ray direction is 0 to still
initialize invSpacing.
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.
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.
The benchmarking header files were not listed. Not a huge deal since
these files do not need to be installed, but they should be listed
anyway. Changed the vtkm_save_benchmarks CMake macro to be able to list
headers.
Also moved everything from BenchmarkDeviceAdapter.h to
BenchmarkDeviceAdapter.cxx. Since this code shouldn't need to be
included by anything except this benchmark, there is no need to have it
in a header file. Plus, the build changes would mean that any change in
the header (where most of the source was) could cause all code in this
directory to recompile. I do not want to set that precedent.
The test is a simple CMake script that finds all files in the build
directory with certain extensions (.h, .cxx, etc.) and makes sure that
the filename is listed somewhere in the CMakeLists.txt file of the same
directory. If the filename is listed in the CMakeLists.txt file, then
there is a good chance it is being addressed by the build.
This should help catch when header files are not being installed. It also
should help verify that test builds are being done on all files. It will
also highlight dead source files.
Not all systems put their OpenGL headers in a directory named GL. (In
particular, OSX decides to be different.) The vtkm/rendering/internal/
OpenGLHeaders.h header takes care of including the OpenGL header on all
platforms.
This is required for installing the files. It is also useful for
developers because it adds the files to IDEs and creates test builds for
the header files. Those test builds highlighted some missing includes.
Adding text annotations to rendering
This adds bitmap font support and two types of text annotations - screen space text and world-space billboard text - as well as enables the labels in the axes.
See merge request !423
Reader should name fields only with their field name
The Legacy VTK file reader was augmenting all the field names with the
type of field. For example, if you had a point scalar field named
"elevation", it would be loaded as "SCALARS:elevation".
This is bad for two reasons. First, it is downright confusing. A tool
like ParaView or VisIt will tell me the field is named "elevation", but
VTK-m will report that field does not exist. Second, the writer does not
follow the same convention. Thus, if you have a loop of read file,
modify, write file, you could end up with fields named
"SCALARS:SCALARS:SCALARS:...".
See merge request !432
The legacy VTK file reader has a condition to flip the bytes in values
when the endian does not match the current system. The problem was that
when reading in a vector, the flip was happening on all bytes of a Vec.
This caused the last components of the Vec to be flipped with the first
components. Instead, we want each component to be flipped independently.
The Legacy VTK file reader was augmenting all the field names with the
type of field. For example, if you had a point scalar field named
"elevation", it would be loaded as "SCALARS:elevation".
This is bad for two reasons. First, it is downright confusing. A tool
like ParaView or VisIt will tell me the field is named "elevation", but
VTK-m will report that field does not exist. Second, the writer does not
follow the same convention. Thus, if you have a loop of read file,
modify, write file, you could end up with fields named
"SCALARS:SCALARS:SCALARS:...".
First, be more explicit when we mean a range of values in a field or a
spacial bounds. Use the Range and Bounds structs in Field and
CoordinateSystem to make all of this more clear (and reduce a bit of
code as well).
The previous version of the bounds code required once less pass across
the data, but significantly increase the size of the resulting library:
Data for VTK-VTK-m interop:
- 7k more symbol table entries
- 1.5MB larger library
Because of the significant savings we need to use a less efficient
implementation that minimized the code size.
Certain algorithms like VertexClustering only work on certain cellset types.
It is pointless to generate the code paths for structured data cell sets,
when the algorithm can't operate on those dataset types.
Template instantiation is useful because when you are creating object files, as
uninstantiated template definitions are not are not added. Fully supporting
explicit instantiation like ITK does will require more code changes, but
this is a very minor step towards that goal.
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.
Made several changes to Window.h that fix the following:
* Fix warning about the member functions being initialized out of order
* Conform indentation to be 2 spaces
* Conform member functions to be capitolized
* Conform the use of "this->" when referencing class members
* Conform using full namespace when using classes
* Be more descriptive in some variable names
* Alphabetize includes
There are a lot of VTK-m coding style issues I would also like to clean
up (such as variable names and using "this->" before member variables),
but it is late and I want to go home.
C++ standard states that all class member variables are initialized in
the order they are declared in the class. Thus, it is considered good
C++ style to have their initialization listing in the constructor to
match the actual order they are initialized. The compiler could give a
warning otherwise.
While I am at it, rename the member variables to be more aligned with
VTK-m coding style (i.e. start with capital letter and be descriptive).
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.
