The intension was that if Camera::Zoom was called with a Float64, it
would call the Float32 version. However, I made a type where it called
itself. The latest version of XCode called me out on this infinite
recursion.
I think this is the equivalent of the compiler calling me a dumb-ass.
Instead of having two separate implementations of MarchingCubes, we have
a single implementation in worklet, and filter uses that.
That does mean that the version in worklet has been updated to support
merging of duplicate point coordinates.
I don't know why, but under some circumstances when compiling with CUDA
and Visual Studio, the compiler was giving syntax errors when the
IteratorFromArrayPortal was using the typename keyword to reference a
type in its superclass. Get around the problem by looking directly in
the superclass.
The VTKM_ASSUME macro uses some of the definitions defined in
Configure.h, but it never included that file. So unless that file
happened to be included before Assume.h, VTKM_ASSUME could be declared
incorrectly.
Actually added the include to Assert.h, which Assume.h includes.
The VTKM_SUPPRESS_EXEC_WARNINGS should go before the template keyword,
but on a couple of methods in FunctionInterfaceDetailPre.h.in it was
after the template keyword.
Add pragmas to disable warnings 4244 and 4800 on Visual Studio when
compiling third party libraries. This gets around some warnings inside
the thrust library.
The build automatically sets some macros when building CUDA files. Some
of the CUDA sources were setting the same macros, which was causing
warnings. Change the code to be more careful about setting preprocessor
macros.
There are several tests in the cont directory that are in header files so
that they can be recompiled for different devices. Make sure that the
tests are exclusively using the device being tested by making the error
device adapter the default.
If any part of the test tries to use the default device (which could be
different than the one being tested), a compile error will occur. Several
of these compile errors are fixed in this commit.
Update the CMake package
These commits update how the CMake configuration sets up the
find_package information (accessed in VTKmConfig.cmake). It
establishes a bunch of components that can be used in the
find_package command to load various aspects like CUDA and
TBB.
See merge request !460
Have VTK-m eat its own dog food when it comes to its configuration. Load
the same configuration for building VTK-m as would be loaded (more or
less) when using find_package(VTKm) in an external project.
This includes adding lots more components to the packages so that all the
setup (e.g. OpenGL, TBB, etc.) can be set up correctly. It is also a
significant change to how these components are declared. The component
configuration is simplified a bit and unified in a single file.
This is a little tricky since they don't seem to have considered that
you will have files in both the source and build directory or that the
file locations will not match exactly with the install locations.
In some cases on windows pointers used as iterators are wrapped in
checked iterators. This is fine for most uses, but you cannot pass them
to a C function as a pointer (as we were doing for OpenGL). This change
converts the checked iterator back to a raw pointer in this case.
There were a few places in the source code where
std::numeric_limits::min and max were used. There is an issue with these
methods on windows because the standard libraries there define macros
with the same name. Get around this problem by either places parentheses
so that they do not look like macros or use the vtkm::Infinity methods
instead.
Microsoft visual studio treats these as keywords. These keywords were
used for pointers on 16-bit architectures. That makes them pretty much
obsolete for any software written in the last 20 years, but happily they
stick around to give us confusing compile errors.
When compiling under VisualStudio we need to first determine if checked
iterators are enabled ( _ITERATOR_DEBUG_LEVEL ). We don't want to use the
NDEBUG key, as we could be inside a project that is in Debug mode with
disabled checked iterators.
Secondly if they are enabled we need to handle the use case of NULL iterators
that get advanced by length zero. This last case is valid, but isn't supported
by the checked iterators so we need to work around it
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.
All of the Camera math (currently) uses 32-bit floats. However, to make
it easier to use the Camera class, I've duplicated the accessor methods
to also accept 64-bit floats.
Resolve conflicting merges
Merge request !445 (Camera enhancements) and merge request !448
(Consolidate background color) had conflicting changes in View.h.
Although git did not pick up on the conflict because each merge modified a
different portion of View.h, the final merge with both of these resulted
in a compile error.
Basically what happened was `Consolidate background color` changed all
the View constructors to reflect changes. `Camera enhancements` added a
new constructor to View using the old construction method. The new
constructor with the old construction method caused an error.
See merge request !451
Fix warning about type conversion
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.
See merge request !450
Merge request !445 (Camera enhancements) and merge request !448
(Consolidate background color) had conflicting changes in View.h.
Although git did not pick up on the conflict because each merge modified a
different portion of View.h, the final merge with both of these resulted
in a compile error.
Basically what happened was `Consolidate background color` changed all
the View constructors to reflect changes. `Camera enhancements` added a
new constructor to View using the old construction method. The new
constructor with the old construction method caused an error.
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
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
