Q100443: Getting started with Scripting and Programming in Katana

Follow

SUMMARY

Katana supports three languages for adding custom code to the application: Python, Lua, and C++. This article gives an overview of how to get started with scripting and programming in Katana and which tasks each language is most appropriate for.

 

MORE INFORMATION

Each of the available languages in Katana has its own set of strengths, so it depends on the specific use case which one is best suited.

 

PYTHON

Python is used widely for rapid application development, especially in the context of APIs to allow users to customize the application, for example when working with projects, working with nodes, customising node types, customising the user interface, or Python-based parameter expressions.

Further examples are described in the Katana User Guide on Scripting with Python and in the following articles which go into detail about different Python workflows:

 

PYTHON - PERFORMANCE CONSIDERATIONS

Where faster performance is required, Python isn’t always an ideal choice (partly due to the dreaded GIL).

In the context of parameter expressions, a faster alternative to Python expressions is available for simple expressions that reference nodes or parameters. They are called Reference Expressions, and you can find further information regarding these in the Katana Developer Guide.

Lua offers better performance, making it a preferred scripting language for scene graph processing operations using OpScript nodes.

 

LUA

Lua is used within the OpScript node in Katana. Using OpScript/Lua it’s possible to access the Op API, which is both faster and more powerful than Python. In particular, the OpScript node allows you to modify the structure of the scene graph hierarchy, such as deleting locations, creating new child locations as well as setting and editing attributes.

Lua represents a reasonable balance between fast development turnaround time for developing operations on the scene graph (also for prototyping more complex operations that are planned to be implemented as Op Types later), and fast execution time and stability as part of cooking a scene.

In certain situations it may be advisable to implement a custom Op type plug-in instead of using OpScript/Lua. Whether this is of advantage depends on the actual use case at hand: the complexity of a project and its assets, the number of operations to be performed, the number of scene graph locations to target. It's advisable to process FX data like particle simulations in Ops/C++, rather than OpScript/Lua.

For an introduction to using OpScript and the Op API, please look at the OpScript tutorials in the Help > Example Projects menu in Katana.

More information on the Op API can be found in the Katana User Guide as well as the Katana Developer Guide.

You may also be interested in the following articles:

 

C++

When performance is critical, for example when working with large data sets, a Lua OpScript can be ported to a C++ Op type plug-in.

Please see the Katana Developer Guide for documentation of the interface, and refer to the example “HelloWorld” Op shipped with the Katana source code in the following location: $KATANA_ROOT/plugins/Src/Ops/HelloWorld

Build instructions can be found here: $KATANA_ROOT/plugins/Src/README.md

For some further hints and instructions on compiling an example Op, please see the following article: Q100326: How to write and test your first custom Op

You may also be interested in the following content:

Q100351: How to query system Graph State data from inside a C++ Op to react to time related values

 

FURTHER READING

Please refer to the Katana User Guide and Developer Guide for guides and further reference for each language:

Python

Lua

C++

    We're sorry to hear that

    Please tell us why