User guide

It is recommended to omit inputs from any high-level ‘generator’ Ops that don’t need to see the incoming scene,

as it encourages users to make node graphs that are ‘wider’, rather than ‘deeper’. These can be more efficient

with multi-threading and permit better caching efficiency. This is by no means a requirement though.

NOTE: Deeply overlapping merges of many inputs can be expensive, while non-overlapping merges are

preferred and significantly cheaper.

12. How do I get system args or GraphState variables into my Op?

GenericOp adds these in for you if you enable ‘addSystemOpArgs’. Alternatively, with NodeTypeBuilder in your

buildOpChainFunc you can:

graphState = interface.getGraphState()

argsGb.set( 'system', graphState.getOpSystemArgs() )

13. I'm getting a bit mixed up about ‘swapping the Op for my children’. I thought the Op Tree was

‘immutable’ while the Scenegraph was being cooked?

One of the key differences between Katana 1.x and 2.x versions is that we keep the network of the Ops that the

nodes represent alive all the time, rather than regenerating them every time parameters change.

This is great for performance, but means the the topology of the Op Tree changes as you add nodes. However,

once the scene graph needs to be evaluated, this top-level Op Tree becomes immutable.

You may find it simpler to think of it as a fixed cookie-cutter template of ‘slots’ that Ops can sit in, rather than a

fixed set of specific Ops. Functions like replaceChildTraversalOp, and the ability to adjust the optype when

creating children, simply changes which Op is in a particular ‘slot’ in the cookie-cutter template when that child

location is cooked.

So, you can’t add new branches but you can easily swap Ops or call extra ones in your slot, in a serial fashion.

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