Schemas / Node graph
rig.node.pin
v1.0.0 · stable maturity: stable 5 fields 4 required
Fields
| Field | Type | Meaning | |
|---|---|---|---|
id |
uint | required | Stable id within the node |
name |
string | required | Pin label (may carry domain hint, e.g. rgba) |
kind |
enumin · out | required | in, out |
type |
propertyType | required | Property datatype id - see properties |
bus |
uint | optional | Optional. rig.node.bus this pin taps; absent = none. An out pin drives the bus; an in pin reads it |
Pin on a rig.node.node.
type vocabulary
Same table as portable property descriptors:
bool, int, uint, float, double, string, vec2, vec3, vec4, quat, entity, enum
Colour is vec4, not a separate type - domain lives in name (e.g. rgba) or the catalog node id. Hosts may draw a colour control for a vec4 pin named rgba.
Empty type = untyped wildcard (link to anything). Prefer concrete types.
Hosts may add prefixed ids (host.foo). Do not invent unprefixed extras (color, any, ...).
Linking
Exact type match always links. Hosts may allow documented coercions at eval (e.g. float to vec2 / vec4) - that is fulfillment, not Contract.
A pin that taps a bus follows the same rules: pin type matches bus type, coercions are host policy, and an in pin with a bus is not also a link target - one source per input.
JSON Schema
Resolves at https://rig.works/schemas/rig.node.pin.schema.json —
raw file.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://rig.works/schemas/rig.node.pin.schema.json",
"title": "rig.node.pin",
"type": "object",
"additionalProperties": false,
"properties": {
"id": {
"$ref": "./_defs.schema.json#/$defs/uint"
},
"name": {
"$ref": "./_defs.schema.json#/$defs/string"
},
"kind": {
"type": "string",
"enum": [
"in",
"out"
]
},
"type": {
"$ref": "./_defs.schema.json#/$defs/propertyType"
},
"bus": {
"$ref": "./_defs.schema.json#/$defs/uint"
}
},
"required": [
"id",
"name",
"kind",
"type"
],
"x-rig-maturity": "stable"
}