The GLEW library is optional, but without it you cannot do OpenGL
interop. The hello_world example uses OpenGL interop, but did not check
that GLEW was available. It tried to use GLEW and an error occured.
On Unix-based systems, you can directly execute a script and the system
will automatically run it through its associated interpreter. However,
on Windows this does not work. You just get an error about the script,
which is just a text file, being an invalid executable.
This was an issue when running pyexpander. Now, Python is called
directly for pyexpander.
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.
Render interface consistency
These changes mostly represent changing the interface to some of
the rendering classes to be more consistent with the reset of VTK-m.
In particular, several exposed class members become private and
are accessed through methods.
There are some other changes to make the interface simpler to
use. One example is consolidating the width/height of the image
to the Canvas. (All other classes refer to the Canvas for the
width/height). Another example is removing the template from
the View class.
See merge request !442
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.
