SUMMARY
This article explains how scene graph data, like location attributes, can be produced and queried using Python.
MORE INFORMATION
Users may wish to write Python scripts that query the value of attributes on scene graph locations. To make this possible, the scene has to be cooked first. A cook represents an evaluation of the scene graph, meaning the node graph has to be evaluated to calculate the scene data. If this step doesn’t happen, the attribute data does not exist and cannot be queried.
This can be achieved by creating a Geolib3 client, which can request scene data to be produced. Please see the following example:
# We first need to get a hold of the runtime the UI is using
runtime = FnGeolib.GetRegisteredRuntimeInstance()
# Transactions are used to batch together actions
txn = runtime.createTransaction()
# Make a client, and attach it to an Op in the tree, we get the Op from a reference to a Node.
client = txn.createClient()
op = Nodes3DAPI.GetOp(txn, NodegraphAPI.GetNode('Render'))
txn.setClientOp(client, op)
# Commit the transaction to the runtime, if we don't the client will exist, but won't yet be pointing to an Op
runtime.commit(txn)
Then you can use the client to cook a location and inspect its attribute values, for example to get the centerOfInterest attribute of a camera location:
location = client.cookLocation('/root/world/cam/camera')
attrs = location.getAttrs()
COI = attrs.getChildByName('geometry.centerOfInterest')
print(COI.getValue())
For more details on Geolib3 and the Op API, please see the Op API section of the Katana User Guide.
Please note that cooking the scene graph can be a computationally expensive operation. Special care should be taken to avoid unnecessary cooking. For example, automatically cooking for every node graph change is not recommended, but cooking in a user-triggered event like a button script would be fine.
If you find yourself wanting to cook extensively to achieve your desired workflow, please consider a different approach that involves Op or OpScripts. Many workflows can be achieved by breaking the problem down into a few Ops working together.
If you have further questions, or if you are having any trouble finding the right workflow for querying attributes, then please open a Support ticket and let us know the issue you are encountering or the desired workflow you are trying to achieve.
For more information on how to open a Support ticket, please refer to Q100064: How to raise a support ticket.
We're sorry to hear that
Please tell us why