Tutorial 19 - Extended Attribute Types
Extended attribute types are so-named because they extend the types of data an attribute can accept from one type to several types. Extended attributes come in two flavours. The _any_ type is the most flexible. It allows a connection with any other attribute type:
"inputs": {
"myAnyAttribute": {
"description": "Accepts an incoming connection from any type of attribute",
"type": "any",
}
}
The union type, represented as an array of type names, allows a connection from a limited subset of attribute types. Here’s one that can connect to attributes of type _float[3]_ and _double[3]_:
"inputs": {
"myUnionAttribute": {
"description": "Accepts an incoming connection from attributes with a vector of a 3-tuple of numbers",
"type": ["float[3]", "double[3]"],
}
}
Note
“union” is not an actual type name, as the type names are specified by a list. It is just the nomenclature used for the set of all attributes that can be specified in this way. More details about union types can be found in omni.graph.docs.ogn_attribute_types.
As you will see in the code examples, the value extracted from the database for such attributes has to be checked for the actual resolved data type. Until an extended attribute is connected its data type will be unresolved and it will not have a value. For this reason _”default”_ values are not allowed on extended attributes.
OgnTutorialExtendedTypes.ogn
The ogn file shows the implementation of a node named “omni.graph.tutorials.ExtendedTypes”, which has inputs and outputs with the extended attribute types.
1{
2 "ExtendedTypes": {
3 "version": 1,
4 "categories": "tutorials",
5 "scheduling": ["threadsafe"],
6 "description": ["This is a tutorial node. It exercises functionality for the manipulation of the extended",
7 "attribute types."
8 ],
9 "uiName": "Tutorial Node: Extended Attribute Types",
10 "inputs": {
11 "floatOrToken": {
12 "$comment": [
13 "Support for a union of types is noted by putting a list into the attribute type.",
14 "Each element of the list must be a legal attribute type from the supported type list."
15 ],
16 "type": ["float", "token"],
17 "description": "Attribute that can either be a float value or a token value",
18 "uiName": "Float Or Token",
19 "unvalidated": true
20 },
21 "toNegate": {
22 "$comment": "An example showing that array and tuple types are also legal members of a union.",
23 "type": ["bool[]", "float[]"],
24 "description": "Attribute that can either be an array of booleans or an array of floats",
25 "uiName": "To Negate",
26 "unvalidated": true
27 },
28 "tuple": {
29 "$comment": "Tuple types are also allowed, implemented as 'any' to show similarities",
30 "type": "any",
31 "description": "Variable size/type tuple values",
32 "uiName": "Tuple Values",
33 "unvalidated": true
34 },
35 "flexible": {
36 "$comment": "You don't even have to have the same shape of data in a union",
37 "type": ["float[3][]", "token"],
38 "description": "Flexible data type input",
39 "uiName": "Flexible Values",
40 "unvalidated": true
41 }
42 },
43 "outputs": {
44 "doubledResult": {
45 "type": "any",
46 "description": ["If the input 'simpleInput' is a float this is 2x the value.",
47 "If it is a token this contains the input token repeated twice."
48 ],
49 "uiName": "Doubled Input Value",
50 "unvalidated": true
51 },
52 "negatedResult": {
53 "type": ["bool[]", "float[]"],
54 "description": "Result of negating the data from the 'toNegate' input",
55 "uiName": "Negated Array Values",
56 "unvalidated": true
57 },
58 "tuple": {
59 "type": "any",
60 "description": "Negated values of the tuple input",
61 "uiName": "Negative Tuple Values",
62 "unvalidated": true
63 },
64 "flexible": {
65 "type": ["float[3][]", "token"],
66 "description": "Flexible data type output",
67 "uiName": "Inverted Flexible Values",
68 "unvalidated": true
69 }
70 }
71 }
72}
OgnTutorialExtendedTypes.cpp
The cpp file contains the implementation of the compute method. It illustrates how to determine and set the data types on extended attribute types.
1// SPDX-FileCopyrightText: Copyright (c) 2021-2024 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
2// SPDX-License-Identifier: LicenseRef-NvidiaProprietary
3//
4// NVIDIA CORPORATION, its affiliates and licensors retain all intellectual
5// property and proprietary rights in and to this material, related
6// documentation and any modifications thereto. Any use, reproduction,
7// disclosure or distribution of this material and related documentation
8// without an express license agreement from NVIDIA CORPORATION or
9// its affiliates is strictly prohibited.
10#include <OgnTutorialExtendedTypesDatabase.h>
11#include <algorithm>
12
13//
14// Attributes whose data types resolve at runtime ("any" or "union" types) are resolved by having connections made
15// to them of a resolved type. Say you have a chain of A->B->C where B has inputs and outputs of these types. The
16// connection from A->B will determine the type of data at B's input and the connection B->C will determine the type
17// of data at B's output (assuming A's outputs and C's inputs are well-defined types).
18//
19// For this reason it is the node's responsibility to verify the type resolution of the attributes as part of the
20// compute method. Any unresolved types (db.Xputs.attrName().resolved() == false) that are required by the compute
21// should result in a warning and compute failure. Any attributes resolved to incompatible types, for example an input
22// that resolves to a string where a number is needed, should also result in a warning and compute failure.
23//
24// It is up to the node to decide how flexible the resolution requirements are to be. In the string/number case above
25// the node may choose to parse the string as a number instead of failing, or using the length of the string as the
26// input number. The only requirement from OmniGraph is that the node handle all of the resolution types it has
27// claimed it will handle in the .ogn file. "any" attributes must handle all data types, even if some types result in
28// warnings or errors. "union" attributes must handle all types specified in the union.
29//
30
31class OgnTutorialExtendedTypes
32{
33public:
34 static bool compute(OgnTutorialExtendedTypesDatabase& db)
35 {
36 bool computedOne = false;
37
38 auto typeWarning = [&](const char* message, const Type& type1, const Type& type2)
39 { db.logWarning("%s (%s -> %s)", message, getOgnTypeName(type1).c_str(), getOgnTypeName(type2).c_str()); };
40 auto typeError = [&](const char* message, const Type& type1, const Type& type2)
41 { db.logError("%s (%s -> %s)", message, getOgnTypeName(type1).c_str(), getOgnTypeName(type2).c_str()); };
42
43 auto computeSimpleValues = [&]()
44 {
45 // ====================================================================================================
46 // Compute for the union types that resolve to simple values.
47 // Accepted value types are floats and tokens. As these were the only types specified in the union
48 // definition the node does not have to worry about other numeric types, such as int or double.
49
50 // The node can decide what the meaning of an attempt to compute with unresolved types is.
51 // For this particular node they are treated as silent success.
52 const auto& floatOrToken = db.inputs.floatOrToken();
53 auto& doubledResult = db.outputs.doubledResult();
54
55 if (floatOrToken.resolved() && doubledResult.resolved())
56 {
57 // Check for an exact type match for the input and output
58 if (floatOrToken.type() != doubledResult.type())
59 {
60 // Mismatched types are possible, and result in no compute
61 typeWarning("Simple resolved types do not match", floatOrToken.type(), doubledResult.type());
62 return false;
63 }
64
65 // When extracting extended types the templated get<> method returns an object that contains the cast
66 // data. It can be cast to a boolean for quick checks for matching types.
67 //
68 // Note: The single "=" in these if statements is intentional. It facilitates one-line set-and-test of
69 // the
70 // typed values.
71 //
72 if (auto floatValue = floatOrToken.get<float>())
73 {
74 // Once the existence of the cast type is verified it can be dereferenced to get at the raw data,
75 // whose types are described in the tutorial on bundled data.
76 if (auto doubledValue = doubledResult.get<float>())
77 {
78 *doubledValue = *floatValue * 2.0f;
79 }
80 else
81 {
82 // This could be an assert because it should never happen. The types were confirmed above to
83 // match, so they should have cast to the same types without incident.
84 typeError("Simple types were matched as bool then failed to cast properly", floatOrToken.type(),
85 doubledResult.type());
86 return false;
87 }
88 }
89 else if (auto tokenValue = floatOrToken.get<OgnToken>())
90 {
91 if (auto doubledValue = doubledResult.get<OgnToken>())
92 {
93 std::string inputString{ db.tokenToString(*tokenValue) };
94 inputString += inputString;
95 *doubledValue = db.stringToToken(inputString.c_str());
96 }
97 else
98 {
99 // This could be an assert because it should never happen. The types were confirmed above to
100 // match, so they should have cast to the same types without incident.
101 typeError("Simple types were matched as token then failed to cast properly",
102 floatOrToken.type(), doubledResult.type());
103 return false;
104 }
105 }
106 else
107 {
108 // As Union types are supposed to restrict the data types being passed in to the declared types
109 // any unrecognized types are an error, not a warning.
110 typeError("Simple types resolved to unknown types", floatOrToken.type(), doubledResult.type());
111 return false;
112 }
113 }
114 else
115 {
116 // Unresolved types are reasonable, resulting in no compute
117 return true;
118 }
119 return true;
120 };
121
122 auto computeArrayValues = [&]()
123 {
124 // ====================================================================================================
125 // Compute for the union types that resolve to arrays.
126 // Accepted value types are arrays of bool or arrays of float, which are extracted as interfaces to
127 // those values so that resizing can happen transparently through the fabric.
128 //
129 // These interfaces are similar to what you've seen in regular array attributes - they support resize(),
130 // operator[], and range-based for loops.
131 //
132 const auto& toNegate = db.inputs.toNegate();
133 auto& negatedResult = db.outputs.negatedResult();
134
135 if (toNegate.resolved() && negatedResult.resolved())
136 {
137 // Check for an exact type match for the input and output
138 if (toNegate.type() != negatedResult.type())
139 {
140 // Mismatched types are possible, and result in no compute
141 typeWarning("Array resolved types do not match", toNegate.type(), negatedResult.type());
142 return false;
143 }
144
145 // Extended types can be any legal attribute type. Here the types in the extended attribute can be
146 // either an array of booleans or an array of integers.
147 if (auto boolArray = toNegate.get<bool[]>())
148 {
149 auto valueAsBoolArray = negatedResult.get<bool[]>();
150 if (valueAsBoolArray)
151 {
152 valueAsBoolArray.resize(boolArray->size());
153 size_t index{ 0 };
154 for (auto& value : *boolArray)
155 {
156 (*valueAsBoolArray)[index++] = !value;
157 }
158 }
159 else
160 {
161 // This could be an assert because it should never happen. The types were confirmed above to
162 // match, so they should have cast to the same types without incident.
163 typeError("Array types were matched as bool[] then failed to cast properly", toNegate.type(),
164 negatedResult.type());
165 return false;
166 }
167 }
168 else if (auto floatArray = toNegate.get<float[]>())
169 {
170 auto valueAsFloatArray = negatedResult.get<float[]>();
171 if (valueAsFloatArray)
172 {
173 valueAsFloatArray.resize(floatArray->size());
174 size_t index{ 0 };
175 for (auto& value : *floatArray)
176 {
177 (*valueAsFloatArray)[index++] = -value;
178 }
179 }
180 else
181 {
182 // This could be an assert because it should never happen. The types were confirmed above to
183 // match, so they should have cast to the same types without incident.
184 typeError("Array types were matched as float[] then failed to cast properly", toNegate.type(),
185 negatedResult.type());
186 return false;
187 }
188 }
189 else
190 {
191 // As Union types are supposed to restrict the data types being passed in to the declared types
192 // any unrecognized types are an error, not a warning.
193 typeError("Array type not recognized", toNegate.type(), negatedResult.type());
194 return false;
195 }
196 }
197 else
198 {
199 // Unresolved types are reasonable, resulting in no compute
200 return true;
201 }
202 return true;
203 };
204
205 auto computeTupleValues = [&]()
206 {
207 // ====================================================================================================
208 // Compute for the "any" types that only handle tuple values. In practice you'd only use "any" when the
209 // type of data you handle is unrestricted. This is more an illustration to show how in practical use the
210 // two types of attribute are accessed exactly the same way, the only difference is restrictions that the
211 // OmniGraph system will put on potential connections.
212 //
213 // For simplicity this node will treat unrecognized type as a warning with success.
214 // Full commentary and error checking is elided as it will be the same as for the above examples.
215 // The algorithm for tuple values is a component-wise negation.
216 const auto& tupleInput = db.inputs.tuple();
217 auto& tupleOutput = db.outputs.tuple();
218
219 if (tupleInput.resolved() && tupleOutput.resolved())
220 {
221 if (tupleInput.type() != tupleOutput.type())
222 {
223 typeWarning("Tuple resolved types do not match", tupleInput.type(), tupleOutput.type());
224 return false;
225 }
226
227 // This node will only recognize the float[3] and int[2] cases, to illustrate that tuple count and
228 // base type are both flexible.
229 if (auto float3Input = tupleInput.get<float[3]>())
230 {
231 if (auto float3Output = tupleOutput.get<float[3]>())
232 {
233 (*float3Output)[0] = -(*float3Input)[0];
234 (*float3Output)[1] = -(*float3Input)[1];
235 (*float3Output)[2] = -(*float3Input)[2];
236 }
237 }
238 else if (auto int2Input = tupleInput.get<int[2]>())
239 {
240 if (auto int2Output = tupleOutput.get<int[2]>())
241 {
242 (*int2Output)[0] = -(*int2Input)[0];
243 (*int2Output)[1] = -(*int2Input)[1];
244 }
245 }
246 else
247 {
248 // As "any" types are not restricted in their data types but this node is only handling two of
249 // them an unrecognized type is just unimplemented code.
250 typeWarning("Unimplemented type combination", tupleInput.type(), tupleOutput.type());
251 return true;
252 }
253 }
254 else
255 {
256 // Unresolved types are reasonable, resulting in no compute
257 return true;
258 }
259 return true;
260 };
261
262 auto computeFlexibleValues = [&]()
263 {
264 // ====================================================================================================
265 // Complex union type that handles both simple values and an array of tuples. It illustrates how the
266 // data types in a union do not have to be related in any way.
267 //
268 // Full commentary and error checking is elided as it will be the same as for the above examples.
269 // The algorithm for tuple array values is to negate everything in the float3 array values, and to reverse
270 // the string for string values.
271 const auto& flexibleInput = db.inputs.flexible();
272 auto& flexibleOutput = db.outputs.flexible();
273
274 if (flexibleInput.resolved() && flexibleOutput.resolved())
275 {
276 if (flexibleInput.type() != flexibleOutput.type())
277 {
278 typeWarning("Flexible resolved types do not match", flexibleInput.type(), flexibleOutput.type());
279 return false;
280 }
281
282 // Arrays of tuples are handled with the same interface as with normal attributes.
283 if (auto float3ArrayInput = flexibleInput.get<float[][3]>())
284 {
285 if (auto float3ArrayOutput = flexibleOutput.get<float[][3]>())
286 {
287 size_t itemCount = float3ArrayInput.size();
288 float3ArrayOutput.resize(itemCount);
289 for (size_t index = 0; index < itemCount; index++)
290 {
291 (*float3ArrayOutput)[index][0] = -(*float3ArrayInput)[index][0];
292 (*float3ArrayOutput)[index][1] = -(*float3ArrayInput)[index][1];
293 (*float3ArrayOutput)[index][2] = -(*float3ArrayInput)[index][2];
294 }
295 }
296 }
297 else if (auto tokenInput = flexibleInput.get<OgnToken>())
298 {
299 if (auto tokenOutput = flexibleOutput.get<OgnToken>())
300 {
301 std::string toReverse{ db.tokenToString(*tokenInput) };
302 std::reverse(toReverse.begin(), toReverse.end());
303 *tokenOutput = db.stringToToken(toReverse.c_str());
304 }
305 }
306 else
307 {
308 typeError("Unrecognized type combination", flexibleInput.type(), flexibleOutput.type());
309 return false;
310 }
311 }
312 else
313 {
314 // Unresolved types are reasonable, resulting in no compute
315 return true;
316 }
317
318 return true;
319 };
320
321 // This approach lets either section fail while still computing the other.
322 computedOne = computeSimpleValues();
323 computedOne = computeArrayValues() || computedOne;
324 computedOne = computeTupleValues() || computedOne;
325 computedOne = computeFlexibleValues() || computedOne;
326
327 if (!computedOne)
328 {
329 db.logWarning("None of the inputs had resolved type, resulting in no compute");
330 }
331 return !computedOne;
332 }
333
334 static void onConnectionTypeResolve(const NodeObj& nodeObj)
335 {
336 // The attribute types resolve in pairs
337 AttributeObj pairs[][2]{ { nodeObj.iNode->getAttributeByToken(nodeObj, inputs::floatOrToken.token()),
338 nodeObj.iNode->getAttributeByToken(nodeObj, outputs::doubledResult.token()) },
339 { nodeObj.iNode->getAttributeByToken(nodeObj, inputs::toNegate.token()),
340 nodeObj.iNode->getAttributeByToken(nodeObj, outputs::negatedResult.token()) },
341 { nodeObj.iNode->getAttributeByToken(nodeObj, inputs::tuple.token()),
342 nodeObj.iNode->getAttributeByToken(nodeObj, outputs::tuple.token()) },
343 { nodeObj.iNode->getAttributeByToken(nodeObj, inputs::flexible.token()),
344 nodeObj.iNode->getAttributeByToken(nodeObj, outputs::flexible.token()) } };
345 for (auto& pair : pairs)
346 {
347 nodeObj.iNode->resolveCoupledAttributes(nodeObj, &pair[0], 2);
348 }
349 }
350};
351
352REGISTER_OGN_NODE()
Information on the raw types extracted from the extended type values can be seen in Tutorial 16 - Bundle Data.
OgnTutorialExtendedTypesPy.py
This is a Python version of the above C++ node with exactly the same set of attributes and the same algorithm. It
shows the parallels between manipulating extended attribute types in both languages. (The .ogn file is omitted for
brevity, being identical to the previous one save for the addition of a "language": "python" property.
1"""
2Implementation of the Python node accessing attributes whose type is determined at runtime.
3This class exercises access to the DataModel through the generated database class for all simple data types.
4"""
5
6import omni.graph.core as og
7
8# Hardcode each of the expected types for easy comparison
9FLOAT_TYPE = og.Type(og.BaseDataType.FLOAT)
10TOKEN_TYPE = og.Type(og.BaseDataType.TOKEN)
11BOOL_ARRAY_TYPE = og.Type(og.BaseDataType.BOOL, array_depth=1)
12FLOAT_ARRAY_TYPE = og.Type(og.BaseDataType.FLOAT, array_depth=1)
13FLOAT3_TYPE = og.Type(og.BaseDataType.FLOAT, tuple_count=3)
14INT2_TYPE = og.Type(og.BaseDataType.INT, tuple_count=2)
15FLOAT3_ARRAY_TYPE = og.Type(og.BaseDataType.FLOAT, tuple_count=3, array_depth=1)
16
17
18class OgnTutorialExtendedTypesPy:
19 """Exercise the runtime data types through a Python OmniGraph node"""
20
21 @staticmethod
22 def compute(db) -> bool:
23 """Implements the same algorithm as the C++ node OgnTutorialExtendedTypes.cpp.
24
25 It follows the same code pattern for easier comparison, though in practice you would probably code Python
26 nodes differently from C++ nodes to take advantage of the strengths of each language.
27 """
28
29 def __compare_resolved_types(input_attribute, output_attribute) -> og.Type:
30 """Returns the resolved type if they are the same, outputs a warning and returns None otherwise"""
31 resolved_input_type = input_attribute.type
32 resolved_output_type = output_attribute.type
33 if resolved_input_type != resolved_output_type:
34 db.log_warn(f"Resolved types do not match {resolved_input_type} -> {resolved_output_type}")
35 return None
36 return resolved_input_type if resolved_input_type.base_type != og.BaseDataType.UNKNOWN else None
37
38 # ---------------------------------------------------------------------------------------------------
39 def _compute_simple_values():
40 """Perform the first algorithm on the simple input data types"""
41
42 # Unlike C++ code the Python types are flexible so you must check the data types to do the right thing.
43 # This works out better when the operation is the same as you don't even have to check the data type. In
44 # this case the "doubling" operation is slightly different for floats and tokens.
45 resolved_type = __compare_resolved_types(db.inputs.floatOrToken, db.outputs.doubledResult)
46 if resolved_type == FLOAT_TYPE:
47 db.outputs.doubledResult.value = db.inputs.floatOrToken.value * 2.0
48 elif resolved_type == TOKEN_TYPE:
49 db.outputs.doubledResult.value = db.inputs.floatOrToken.value + db.inputs.floatOrToken.value
50
51 # A Pythonic way to do the same thing by just applying an operation and checking for compatibility is:
52 # try:
53 # db.outputs.doubledResult = db.inputs.floatOrToken * 2.0
54 # except TypeError:
55 # # Gets in here for token types since multiplying string by float is not legal
56 # db.outputs.doubledResult = db.inputs.floatOrToken + db.inputs.floatOrToken
57
58 return True
59
60 # ---------------------------------------------------------------------------------------------------
61 def _compute_array_values():
62 """Perform the second algorithm on the array input data types"""
63
64 resolved_type = __compare_resolved_types(db.inputs.toNegate, db.outputs.negatedResult)
65 if resolved_type == BOOL_ARRAY_TYPE:
66 db.outputs.negatedResult.value = [not value for value in db.inputs.toNegate.value]
67 elif resolved_type == FLOAT_ARRAY_TYPE:
68 db.outputs.negatedResult.value = [-value for value in db.inputs.toNegate.value]
69
70 return True
71
72 # ---------------------------------------------------------------------------------------------------
73 def _compute_tuple_values():
74 """Perform the third algorithm on the 'any' data types"""
75
76 resolved_type = __compare_resolved_types(db.inputs.tuple, db.outputs.tuple)
77 # Notice how, since the operation is applied the same for both recognized types, the
78 # same code can handle both of them.
79 if resolved_type in (FLOAT3_TYPE, INT2_TYPE):
80 db.outputs.tuple.value = tuple(-x for x in db.inputs.tuple.value)
81 # An unresolved type is a temporary state and okay, resolving to unsupported types means the graph is in
82 # an unsupported configuration that needs to be corrected.
83 elif resolved_type is not None:
84 type_name = resolved_type.get_type_name()
85 db.log_error(f"Only float[3] and int[2] types are supported by this node, not {type_name}")
86 return False
87
88 return True
89
90 # ---------------------------------------------------------------------------------------------------
91 def _compute_flexible_values():
92 """Perform the fourth algorithm on the multi-shape data types"""
93
94 resolved_type = __compare_resolved_types(db.inputs.flexible, db.outputs.flexible)
95 if resolved_type == FLOAT3_ARRAY_TYPE:
96 db.outputs.flexible.value = [(-x, -y, -z) for (x, y, z) in db.inputs.flexible.value]
97 elif resolved_type == TOKEN_TYPE:
98 db.outputs.flexible.value = db.inputs.flexible.value[::-1]
99
100 return True
101
102 # ---------------------------------------------------------------------------------------------------
103 compute_success = _compute_simple_values()
104 compute_success = _compute_array_values() and compute_success
105 compute_success = _compute_tuple_values() and compute_success
106 compute_success = _compute_flexible_values() and compute_success
107
108 # ---------------------------------------------------------------------------------------------------
109 # As Python has a much more flexible typing system it can do things in a few lines that require a lot
110 # more in C++. One such example is the ability to add two arbitrary data types. Here is an example of
111 # how, using "any" type inputs "a", and "b", with an "any" type output "result" you can generically
112 # add two elements without explicitly checking the type, failing only when Python cannot support
113 # the operation.
114 #
115 # try:
116 # db.outputs.result = db.inputs.a + db.inputs.b
117 # return True
118 # except TypeError:
119 # a_type = inputs.a.type().get_type_name()
120 # b_type = inputs.b.type().get_type_name()
121 # db.log_error(f"Cannot add attributes of type {a_type} and {b_type}")
122 # return False
123
124 return True
125
126 @staticmethod
127 def on_connection_type_resolve(node) -> None:
128 # There are 4 sets of type-coupled attributes in this node, meaning that the base_type of the attributes
129 # must be the same for the node to function as designed.
130 # 1. floatOrToken <-> doubledResult
131 # 2. toNegate <-> negatedResult
132 # 3. tuple <-> tuple
133 # 4. flexible <-> flexible
134 #
135 # The following code uses a helper function to resolve the attribute types of the coupled pairs. Note that
136 # without this logic a chain of extended-attribute connections may result in a non-functional graph, due to
137 # the requirement that types be resolved before graph evaluation, and the ambiguity of the graph without knowing
138 # how the types are related.
139 og.resolve_fully_coupled(
140 [node.get_attribute("inputs:floatOrToken"), node.get_attribute("outputs:doubledResult")]
141 )
142 og.resolve_fully_coupled([node.get_attribute("inputs:toNegate"), node.get_attribute("outputs:negatedResult")])
143 og.resolve_fully_coupled([node.get_attribute("inputs:tuple"), node.get_attribute("outputs:tuple")])
144 og.resolve_fully_coupled([node.get_attribute("inputs:flexible"), node.get_attribute("outputs:flexible")])