Commit Graph

61 Commits

Author SHA1 Message Date
dpugmire
d755e43dec Use ArrayHandleCompositeVector to represent separated point arrays for DataSetBuilderExplicit.h. 2016-01-06 13:47:34 -05:00
Kenneth Moreland
9cd8cb22eb Make PrintSummary actually work for Field and CoordinateSystem.
The PrintSummary for CoordinateSystem went in an infinite loop. It was
supposed to call PrintSummary of its superclass (Field), but instead it
called itself.

The PrintSummary for Field only worked for fields of type vtkm::Float32.
To make it work for all array types, I added a PrintSummary method to
DynamicArrayHandle, and Field calls that without trying to cast to a
static type.
2015-08-27 10:20:30 -06:00
Kenneth Moreland
a99f828ca3 CoordinateSystem handles uniform point coordinates.
The point of making CoordinateSystem a special type of Field object
was so that it could handle special array types like implicit regular
point coordinates. Overload the GetData and GetBounds methods to
properly handle this type of array.
2015-08-25 14:38:50 -06:00
Kenneth Moreland
9f624f0a36 Have CoordinateSystem inherit from Field
Previously, coordinate systems in a DataSet simply pointed to field data
specifying the coordinate information (although the ability to get that
back out of the DataSet was missing). This makes sense since point
coordinates are in fact just fields with a particular semantic meaning
to them.

However, there is an issue with this approach. It turns out that there
are special representations that are very common for point coordinates
and very uncommon for other types of fields. For example, a uniform
(a.k.a. regular or image) grid has point coordinates that are easily
derived from the point index, but such fields are quite uncommon
elsewhere.

Representing this kind of structure in the Field list of a DataSet is
problematic. Either all fields have to check to see if they are this
type, which will cause an explosion of unnecessary generated code, or
you will have to actually write out the coordinates in memory, which is
really wasteful but what was done previously.

However, by storing fields representing coordinate systems in a separate
batch, we can use these special types without the stated explosion.
2015-08-25 14:38:41 -06:00
Kenneth Moreland
19db32f084 Conform DataSet classes to coding practices better
The most common changes were making class members uppercase and spelled
out, adding "this->" whenever a class member is used, and declare
functions and members with export macros. Also fixed some uses of int
(instead of vtkm::Id or something similar) and a bit of indentation. I
also sprinkled some const goodness over the code.

It should be noted that I had about a week delay between first making
these changes and checking them in. In the mean time Sujin also made
some similar changes, so there might be some repetative changes.
2015-07-27 12:49:42 -06:00
Robert Maynard
25722fec2e Merge 'origin/datamodel-design' into datamodel-design
Conflicts:
	vtkm/cont/ExplicitConnectivity.h
	vtkm/cont/Field.h
2015-05-29 13:54:10 -04:00
Dave Pugmire
089864d6f3 minor fixes and code cleanup for merge to trunk.
added vtkm_cont_export to ExplicitConnectivity classes.
2015-05-29 12:48:31 -04:00
Robert Maynard
7552509e4b Include all the new DataSet header in CMakeLists.
This will make sure that we properly install these headers.
2015-05-29 12:07:46 -04:00
Robert Maynard
a61989a6d5 Redesign RegularStructure and RegularConnectivity to use vtkm::Vec.
By having them use vtkm::Vec the code becomes safer ( no bad indexes on dim=2).
Plus CellSetStructured becomes super simple.
2015-05-28 16:49:40 -04:00
Dave Pugmire
e1bbda8cae Add PrintSummary() for DataSet. 2015-05-20 15:26:10 -04:00
Jeremy Meredith
c55d764c50 adding coordinate systems instead of axis indices. 2015-05-20 12:46:00 -04:00