History for Fields

changed:
-
Much of the core of cmgui is representations of fields, values defined in
		terms of some underlying coordinate system.  Generally this is finite
		element based where the underlying coordinate system is the 0-1 n
		dimenisional xi space of a series of piecewise elements.  These fields
		are finite element fields.
These fields are evaluated at locations, either nodes, which directly define
		the values of a field, or xi positions within an element which
		interpolate the nodal values.

In addition, cmgui has the concept of "computed fields".  These are
		mathematical operators which operate on other fields.  The operation
		may have constant parameters as well as input fields.
There are many operators that work on a single input field,
		such as trigonometric functions, image_processing_filters, clamps,
		masks, normalise, sum_components and so on.
There are also binary operators such as add (which adds the components of
		two fields with optional weightings) and multiply_components.
These fields are stored as mathematical operators (no extra storage is made)
		and whenever you calculate on them they calculate their source fields
		and then operate on the result.
This means that when you want to write out such a field you currently have to
		create a finite_element field that has the correct storage (most easily
		by copying an exnode/exelem file and renaming the field defined in it)
		and evaluate the computed field into that finite element field.  You can
		then write out the finite_element field.  You should be aware that as
		many of the computed field operators are non linear the same basis
		functions will not in general be sufficient to capture completely the 
		computed field.

In cmgui images can be treated as another field.  Currently you specify a
		field which is evaluated at the element_xi location and the colour of
		the texture at the point returned.  This could be improved if you do not
		need to render your field on finite_element geometry to add a pixel
		location to the computed_field evaluation pipeline.

Another long standing problem is the distinction between spatially varying
		field inputs and constant inputs.  For example there is a separate
		"multiply_components" field and "scale" field.  The first one performs a
		multiplication between each component in two fields.  The second takes a
		single field and multiplies each component by a constant scaling factor,
		which is equivalent to a multiply_components field where the second
		field is constant.  This duplication of many operations is unhelpful and
		so a succinct way of creating the required constant field to allow the
		multiply_components to replace the scale_field would be much better.

The commands for each field are parsed into an html document here: http://cmiss.bioeng.auckland.ac.nz/development/help/cmgui/gfx/index.html#gfx~define~field

The original example explanation of computed fields is in example al.
http://cmiss.bioeng.auckland.ac.nz/development/examples/a/al/index.html