User guide

• Ops also have visibility on the incoming scene, whereas SGGs do not.

This means you no longer patch together the data in a piecemeal fashion. This can greatly simplify the required code,

but, on occasions, may have a higher cost where deferred attribute loading is made possible by the source data. This

also allows you to do perform actions like copying an entire hierarchy from another part of the scenegraph under

the current location.

In Katana post-2.0v1 versions, whenever there is an attempt to access any attribute at a location, Katana calculates

all the attributes at the location. Previously, the granularity of calculating attribute data was at the group level, but

now it's at the whole-location level. This means that if there is heavy computation at any location, it's advisable to

determine whether the location needs to be read or not by only accessing data from the parent, by having bounds,

for example, on the parent.

Ops Versus Attribute Modifiers

Compared to SGGs, Ops and AMPs are much closer in that they both get attributes and set them at the current

location. The main differences between Ops and AMPs are that:

• Ops can also create new (potential) child locations, or remove existing ones,

• Ops call other Ops, or change which Op runs at child locations,

• Ops can also see multiple inputs, which allows complex sets or merging to be performed, and

• Ops can delete the current location, the equivalent of Pruning, with the use of DeleteSelf.

Defining the getAttr and getOutputAttr Functions

In Geolib3 Ops, there are two ways to query local attributes. Depending on which APIs you used in Katana 1.x, they

may differ slightly from what you are used to. In Katana 2.0v1 and later versions, the rules are straightforward:

• getAttr always returns the attribute as set in the scene present at the input to the Op.

• getOutputAttr returns the attribute as it currently stands at the location.

This means that if you follow setAttr with getAttr you always see the input value, not the result of your setAttr

call. If you want to see the result if your setAttr call, use getOutputAttr instead.

This also means that if you provide an alternate location to query the attr at, for example, getAttr( "foo",

"/root/world/geo/bar") you don't see any of the effects of your Op, if it has been set to run there.

NOTE: The getOutputAttr call does not support querying at other locations, for reasons of infinite

recursion, amongst others.

9 PORTING PLUG-INS | OPS VERSUS ATTRIBUTE MODIFIERS