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
