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.
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.
