SoField is the abstract base class for all fields. Fields are the data elements contained within nodes and are the input values for engines. Each node or engine class specifies a set of fields and associates a name with each. These names define the semantics of the field (e.g., the SoCube node contains three float fields named width, height, and depth). Field classes provide the access methods that indirectly allow editing and querying of data within nodes.

There are two abstract subclasses of SoField: SoSField is the base class for all single-valued field classes and SoMField is the base class for all multiple-valued fields, which contain dynamic arrays of values. Subclasses of SoSField have an SoSF prefix, and subclasses of SoMField have an SoMF prefix. See the reference pages for SoSField and SoMField for additional methods.

Fields are typically constructed only within node or engine instances; if you need a field that is not part of a node or engine, you can create a GlobalField; see the methods on SoDB for creating global fields.

Fields can be connected either directly to another field, or can be connected to the output of an engine. The value of a field with a connection will change when the thing it is connected to changes. For example, consider a field "A" that is connected from "B" (by A->connectFrom(B)). When B's value is changed, A's value will also change. Note that A and B may have different values, even if they are connected: if A's value is set after B's value, A's value will be different from B's until B's value is set.

A field can be connected to several other fields, but can be connected from only one source.

It is possible (and often useful) to create loops of field connections (for example, A connected from B and B connected from A). If there are loops, then the rule is that the last setValue() done overrides any connections in to that value. You can think of setting the value of a field as immediately propagating that value forward into all the fields it is connected to, with the propagation stopping at the place where the original setValue() occurred if there is a connection loop. (Actually, a more efficient mechanism than this is used, but the semantics are the same.)

If you try to connect two fields of differing types, Inventor will automatically try to insert a field converter engine between them to convert values from one type into the other. Inventor has most reasonable conversions built-in (multiple-valued field to single-valued and vice versa, anything to SoSFString, anything to SoSFTrigger, float/short/unsigned short/int32_t/uint32_t/etc numeric conversions, etc). You can add field converters using SoDB's extender method addConverter(); see the SoDB.h header file for details. You can also find out if a converter is available with the SoDB::getConverter() method.

Fields each define their own file format for reading and being written to files, but all fields follow the same conventions:

Fields in a node or engine are written as the name of the field followed by the field's value; fields are not written if they have not been modified since they were created (if they have their default value).

The ignored flag is written as a "~" character after the field's value (if the field's value is its default value, just the "~" is written).

Field connections are written as an "=" followed by the container of the field or engine output that the field is connected to, followed by a "." and the name of the field or engine output. For example:

Global fields are written as part of an internal SoFieldContainer class called GlobalField, which writes out an SoSFName field named type whose value is the type of the global field, followed by a field of that type whose name is the name of the global field. For example, a global uint32_t field called "FrameCounter" whose value is 494 would be written as: