Connections

A connection is an FBX SDK data structure that manages a two-way relationship between FBX objects and /or FBX properties.

In a connection, one side of the relationship is the source, and the other side is the destination.

“Source” and “destination” are arbitrary terms that are used in method names (e.g., GetSRCObjectCount(), ConnectDstObject()) and in the reference documentation. The semantics (or the meaning) of the relationship (e.g., parent/child, a material applied to a mesh) usually has nothing to do with sources and destinations.

As you will see below, the semantics of the relationship are almost always meaningful if you make the following “translations”:

Replace “destination” by “container” or “contains”.
Replace “source” by “belongs to” or “is a member of” or “member”.

Connections can involve FBX objects, FBX properties, or both.

There are four types of connections:

OO: Object (source) to Object (destination).
OP: Object (source) to Property (destination).
PO: Property (source) to Object (destination).
PP: Property (source) to Property (destination).

Translate “source to destination” as “member of container”.

Any object or a property can have, at the same time:

0..n connections to source objects.
0..n connections to source properties.
0..n connections to destination objects.
0..n connections to destination properties.

Some relationships between FBX objects are implemented by connections, but the use of connections is not explicit. For example:

A parent/child relationship between two FBX nodes is normally created by the parent node calling AddChild (*myChildNode). The child node is actually a source object. Translation: “The child belongs to the parent.”
A node's relationship to a node attribute is normally created by the node calling SetNodeAttribute (KFbxNodeAttribute *pNodeAttribute). The node attribute is actually a source object. Translation: “The node contains its node attribute.”

Many important and complex relationships among many FBX objects are explicitly implemented by connections. For example:

Materials are connected as sources to their nodes. One node can be connected to many materials, and one material can be connected to many nodes. Translation: “A material can belong to many nodes, and one node can contain many materials.”
Constraints are implemented by connections that can involve several objects.

Connections are not managed as objects of one particular class. Connections are managed by methods of class KFbxObject and class KFbxProperty.

KFbxObject has methods that manage the relationship between:

this object and 0..n source objects.
this object and 0..n destination objects.
this object and 0..n source properties.
this object and 0..n destination properties.

These methods include ConnectSrcObject, GetSourceObjectCount, Disconnect, etc.

KFbxProperty has methods that manage the relationship between:

this property and 0..n source objects.
this property and 0..n destination objects.
this property and 0..n source properties.
this property and 0..n destination properties.

Both classes also have methods to search for and retrieve objects and properties according to criteria that can be quite complex. See class KFbxCriteria, which is used to specify search criteria.