Skip xformOp Attribute name in omni.graph.node ReadPrimAttribute

Omniverse Core Platform Kit App Template / SDK
1

Operating System:
Windows
Linux
Kit Version:
107 (Kit App Template)
106 (Kit App Template)
105 (Launcher)
Kit Template:
USD Composer
USD Explorer
USD Viewer
Custom
GPU Hardware:
A series (Blackwell)
A series (ADA)
A series
50 series
40 series
30 series
GPU Driver:
Latest
Recommended (573.xx)
Other
Work Flow:
I attempted to use the ReadPrimAttribute node in USD Composer’s Action Graph to read an attribute of type XformOp:translate from a Prim of type Xform.ReadPrimAttribute

Main Issue:
After selecting the Prim, the Attribute name dropdown does not list the existing attribute I need. I noticed that the extension I’m using comes from the auto‑synced extension registry: omni.graph.node version 2.1.6.
In the source file
kit-app-template-main/_build/linux-x86_64/release/extscache/omni.graph.nodes-2.1.6+109.0.2.lx64.r.cp312.u81f/omni/graph/nodes/_impl/templates/template_omni.graph.nodes.ReadPrimAttribute.py,
I found that the Attribute name list is filtered, and all xformOp attributes are excluded. After modifying the source code, I was able to see the attributes I needed.

def _skip_xform_op_attributes(name: str) -> bool:
    """Filter function to skip attributes with 'xformOp' prefix."""
    return not name.startswith("xformOp")

However, the corresponding WritePrimAttribute node does not have this restriction, and it correctly lists all attributes.
Why is this the case?

My question is: What is the reason behind this design?
I know there are other nodes, such as ReadPrimLocalTranslate, that can read Prim transform data. But do I have to use those alternative nodes to achieve this functionality?

I’m also unsure whether omni.graph.nodes‑2.1.6 is the latest version. If not, how can I obtain the newest one? I noticed that the offline air‑gap extension registry from NGC Catalog only provides version 2.1.5, while the official kit‑omnigraph repository shows version 2.11.0.

Doc ReadPrimAttribute

Additionally, I saw in the Changelog for version 2.1.3 a note saying:
“Fix a threading issue in ReadPrimAttribute node.”
What does this refer to, and could it be related to the behavior I’m seeing?
Reproduction Steps:
Error Code:

2

The omission of xformOp attributes from ReadPrimAttribute is an intentional design constraint: that node is not meant to work with USD transform ops, which are handled by dedicated transform nodes, while WritePrimAttribute remains generic and is allowed to write any attribute name (including xformOp:*). docs.omniverse.nvidia

What the docs say

  • The generated documentation for ReadPrimAttribute explicitly states:
    “Note that xformOp attributes are not supported, use ReadPrimLocalTransform instead.” docs.omniverse.nvidia
  • The public docs you linked are a slightly different version but describe the same basic node and do not contradict this. docs.omniverse.nvidia

So the filter function you found in template_omni.graph.nodes.ReadPrimAttribute.py is enforcing exactly that documented design decision: to hide xformOp:* from the Attribute Name list so users are steered toward transform‑specific nodes such as ReadPrimLocalTransform / ReadPrimLocalTranslate for transforms. docs.omniverse.nvidia

Why ReadPrimAttribute is restricted but WritePrimAttribute is not

Underlying reasons, matching how USD transforms work:

  • Transform data in USD is represented as a stack of ops (xformOp:translate, xformOp:rotateXYZ, etc.) on UsdGeomXformable, with ordering, composition, and optional suffixes. docs.omniverse.nvidia
  • Reading transforms correctly requires understanding that stack and evaluating it at a time code; Omniverse provides specialized nodes (e.g. ReadPrimLocalTransform, ReadPrimLocalTranslate) that wrap this correctly. docs.omniverse.nvidia
  • A generic attribute reader like ReadPrimAttribute would see each xformOp:* as “just an attribute” and could easily give misleading or partially composed values, especially if users expect a full local transform rather than a single op.

By contrast:

  • WritePrimAttribute is designed as a low‑level “hammer”: it simply sets the value of the named attribute and does nothing if the prim/attribute is missing or of incompatible type. docs.omniverse.nvidia
  • Authoring to xformOp:translate via WritePrimAttribute is explicitly documented and used in official tutorials, which show setting xformOp:translate on torus prims and others. docs.omniverse.nvidia
  • Because WritePrimAttribute is already advertised as a generic authoring node and used in examples with xformOp:*, there is no equivalent “safety filter” there.

In short: ReadPrimAttribute is intentionally “safe and high‑level” for non‑transform attributes, while transform reading is delegated to transform nodes; WritePrimAttribute is intentionally “low‑level and generic,” so it remains unrestricted. docs.omniverse.nvidia

3

Hi Richard, thank you very much for your detailed explanation. I can now understand how this node works. I’ll try following the instructions in the official documentation.
Thanks again and have a great day!

4

You are welcome