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
The remove boost::shared_ptr and the rendering library branches where
developed simultaneously, and thus some of the rendering library
implementation was using boost::shared_ptr like the old code. Bring up
to date with the rest of VTK-m by using std::shared_ptr instead.
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 clang compiler was running into linker errors constructors of
classes with virtual methods that were inline and destructors that were
not declared at all. In this case, the compiler was not creating
everything needed by a virtual table and the link died.
I noticed that Visual Studio was taking an insane amount of time to
compile BitmapFontFactory.cxx (~20 minutes). Following some suggestions
on stackoverflow (http://stackoverflow.com/questions/7893850/long-
compile-times-in-visual-c-2010-with-large-static-arrays) I changed the
arrays to be static const (something that is more viable when compiling
a library instead of header-only). The compile after this changes seems
basically immediate now.
Also made the TextAnnotation classes conform better to VTK-m coding
style. Specifically, changed the order of words in subclass names (e.g.
TextAnnotationBillboard instead of BillboardTextAnnotation) and broke
out each subclass into its own header/source files.
When things in the rendering library need to execute things in parallel
(outside of another rendering library like OpenGL) it should run it on
available parallel devices. This means using TryExecute to attempt on
whatever devices may be available. It also means that some of the
sources must be compiled with CUDA's nvcc. To enable this, made a code
wrapping mechanism to compile within a .cu file.
I have noticed at least on my windows machine that source code that uses
the rendering package is taking a long time to compile. The rendering
library does not rely much on templates and more on virtual methods.
Thus, it is a good candidate for moving to a library so that it need be
compiled only once.
This sets up the configure scripts to create the library. There is also
a simple port of one class to the library. More will follow.
Fix precision warnings when FloatDefault is 64 bit
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
See merge request !526
When VTKm_USE_DOUBLE_PRECISION is on (not the default), then
vtkm::FloatDefault is set to 64 bit values. There was some code that was
coded for 32 bit and never checked for 64 bit (on all compilers).
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 VTKmConfigureComponents.cmake file has lots of careful configuration
of many of VTK-m components and dependent libraries (like OpenGL,
OSMesa, etc.) that takes care of several corner cases. The configuration
is consolidated here so that it can be consistent across the many
directories in VTK-m as well as other projects that use VTK-m.
Recent changes to the configuration in rendering circumvented these and
directly tried to configure dependent rendering libraries. This is wrong
(and more importantly broke my OSX build).
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.
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.
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.
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.
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.