Sandia National Laboratories recently changed management from the
Sandia Corporation to the National Technology & Engineering Solutions
of Sandia, LLC (NTESS). The copyright statements need to be updated
accordingly.
5429f120 fixed energy error and fix for ray camera
ac784330 Merge remote-tracking branch 'upstream/master' into x_ray_add_emmission
521e445b emission now functioning
52959d91 testing emission
5fc80517 initial version on absorption and emission integration
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !893
There was a case of bad casting where a Float32 that should be in the
range between 0 and 1 was cast to an Id and then multiplied by the size
of an array. The intention is to get a proportional index into the
array, but because the float was cast to an int first, you get either
the first or last index.
Instead, first cast the size of the array to a Float32, multiply it by
the fraction, and then cast back to an Id. That should give the desired
effect.
Change the VTKM_CONT_EXPORT to VTKM_CONT. (Likewise for EXEC and
EXEC_CONT.) Remove the inline from these macros so that they can be
applied to everything, including implementations in a library.
Because inline is not declared in these modifies, you have to add the
keyword to functions and methods where the implementation is not inlined
in the class.
One of the dashboard was complaining that the bottomLeft variable might
have been used uninitialized because it got set in a condition above it.
In fact, that condition is always true the first during the first
iteration, but it is not worth fighting the compiler over it. Instead,
just initialize the value of bottomLeft when it is constructed.
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).
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.
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.
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.
There are a lot of VTK-m coding style issues I would also like to clean
up (such as variable names and using "this->" before member variables),
but it is late and I want to go home.
C++ standard states that all class member variables are initialized in
the order they are declared in the class. Thus, it is considered good
C++ style to have their initialization listing in the constructor to
match the actual order they are initialized. The compiler could give a
warning otherwise.
While I am at it, rename the member variables to be more aligned with
VTK-m coding style (i.e. start with capital letter and be descriptive).
Several of the methods in View.h were giving me warnings about shadowed
variables because the name of the arguments were the same as some class
member variables. I fixed this by changing the variable names to match
the VTK-m coding convention of using capitalized words for class member
variables and starting lower case letter for method arguments and local
variables.
Since this ended up changing over half of the lines of View.h and
Camera.h anyway, I also made some other modifications to the style to put
it in alignment with VTK-m coding conventions including 2-space
indentation and more descriptive variable names.
