# Fields in Geometry Nodes

## Goals

* Decouple data storage from operations (allowing them to be build and shared separately).
* Use same "texture node group" in geometry nodes and shading nodes.
* User friendly concept of "falloffs" using controller objects in the viewport.

## Approach

The data passed through int/float/... sockets is not a single value anymore, but a "Field". There are float fields, vector fields, etc.

## What is a field

A field is a function that can be evaluated to get a value.
A field can have parameters that are provided by the node evaluating the field.
A field with no parameters is constant and is equivalent to just e.g. a float value.

A field has:
* An output type (float/int/vector/...).
* An set of parameters, each of which has:
* A data type.
* A name/identifier.
* A default value.

Contrary to "fields" in physics, which usually depend on position and time, we don't need to impose this limitation. In practice fields will probably be constant or depend on position though.

A field can also be though of as a way to build expressions with nodes.


## Debugging

Debugging fields is harder than debugging geometry attributes directly, because they are computed lazily and need parameters.
Therefore, fields usually need to be debugged in the context of a geometry.
The simplest approach would just be to have a `Sample Field` node that takes a geometry, a field and an result attribute name as input. The field is then evaluated on every element of e.g. the point domain and the output is stored in a new attribute. This attribute can then be seen in the spreadsheet.
An alternative is to provide viewport visualizations for fields that only depend on position (e.g. showing a vector field as many arrows etc.).