3. Types

All data in a UBF Blueprint has a type.

Data of different types are incompatible, meaning that an Output Port with one type, connected to an Input Port with another type, will not function properly during execution. There is no implicit casting between types.

Data types are supplied for each variable in the JSON structure. If a type field in a Blueprint does not match one of the types below, it is not considered valid UBF.

Since UBF Blueprints are in JSON format, some values of the more complex types are represented in JSON as strings, and should be explicitly cast into the specific type in the Interpreters.

3.1. Primitives

• boolean - Can be true or false.
• float - For decimal values.
• int - If a float is provided, it should be rounded down.
• string

3.2. Complex

• Color - Represents a color value in hex code format. e.g. #FF0000.
• Json - Represents a valid JSON string, e.g. { "Hello": "World" }.

3.3. Object

Data of these types represent objects in the Interpreters, which are passed into and between Blueprints. As such, they are typically stored as pointers and the values for data of these types in UBF Blueprints should always be null.

• Array<T> - Represents an ordered collection of items of the same type. The inner type of an Array can be any other valid UBF Type, including itself.
• Material - Represents a shader material that can be applied to a mesh.
• MeshConfig - Defines how a mesh is spawned, and its properties.
• MeshRenderer - Represents a mesh component in a scene.
• SceneNode - Represents a named object in a scene, with a location, position, and scale.

3.4. Resource<T>

Resource types represent Meshes, Textures, and other Blueprints that can be retreived from the Catalog. The values for Resource types are strings that correspond to the Resource ID found in the Catalog files.

• Resource<Blueprint>
• Resource<GLB>
• Resource<Mesh>
• Resource<Texture>

3.5. Exec

• exec - Represents the flow of execution between nodes in the Graph. Inputs/outputs of type Exec can only be connected to each other. The value for data of type Exec should always be null in a UBF Graph.

3.6. Generic Types

Some Node inputs can accept multiple Types. In these cases, the Node Reference will denote that input with the generic types T, U, or V, and any generic constraints (i.e. a list of all types accepted by that input) will be listed. The UBF Blueprint must still explicitly state the concrete Type, and it must be one of the types listed in the generic constraints. If any type can be passed into the Input, the generic constraint will be 'Any'.

For example, the IsNull Node has an input with a generic constraint, restricted to the types listed. If any of the listed Types are set in the type field for that Node input in the Blueprint JSON, it is a valid UBF Blueprint. If the type is instead set to string instead, it is not valid UBF.