User guide

In Katana 2.0v1 and later, the SGG host Op only sets attributes that you name in getLocalAttrNames when

cooking the location. Consequently, you may need to add any missing attributes from the named list if you were

responding to them before. This also includes the errorMessage attribute that is used for error reporting, which you

may not have previously added to that list.

In Katana 2.0v1 and later, default values are no longer provided for args that weren’t filled in by the node. As such,

you may want to adjust calls to getAttr accordingly, in order to use the non-excepting variant, complete with the

known default values. For example:

FnKatana::IntAttribute attr = args.getChildByName( “myNumberAttr” );

const int value = attr.getValue( 20 /*default*/, false /*don’t throw*/ );

Behavioral Differences for AMPs

Locations are explicitly named upon declaration in Geolib3. The “name” attribute is no longer used and behaves just

like ‘any other attr’. As such, you can’t rename a location using setAttr( “name” ) any more. Additionally getAttr(

“name” ) won’t return the location name, only whatever value another Op may have set it to, which is usually

nothing.

If you need to rename locations, the Rename Node/Op is available, and similar functionality is present within the

CookInterface (copyLocationToChild) if you port your AMP to an Op.

FAQ for Plug-in Porting

1. Can I use my pre-2.0v1 plug-ins?

Yes, you can recompile SGG and AMP plug-in as full Ops, with some header and mild behavioral changes, which

are listed in Recompiling Existing SGG and AMP Plug-ins on the previous page.

2. Why are Ops better?

The Op API is the same API as is used internally by Katana, and this replaces both SGGs and AMPs. That is to say

that you can finally write a Merge or an Instancing Op without jumping through hoops.

3. Anything major I should be aware of now?

The new ‘granularity of data’ is now per-location, in cook, and you have to calculate all of your attributes at the

same time, as well as name your children. Additionally, the name attribute is no longer used, as locations are

explicitly named upon declaration and cook is performed at a named location path.

4. I used ‘ScenegraphContext’ to adapt behavior. How can I replace it?

The simplest match is to port these Contexts to different Ops, and replace the Op for children as you define

them in the way you would construct a different Context when returning getFirstChild or getNextSibiling.

5. I previously passed data to the constructor of my ScenegraphContext. How do I pass down data

now?

OpArgs are the key to this. Replace the OpArgs for the Op with your children. If it's a complex handle, try using

static Op-level caching (though, beware threading), or use the blind data void*.

9 PORTING PLUG-INS | FAQ FOR PLUG-IN PORTING