KATANA FAQ
Contents
Click on a question to jump to the answer:
- What is KATANA?
- What are the system requirements for KATANA?
- How do I buy KATANA?
- Can I use KATANA on Windows or Mac OS X?
- Where was KATANA originally designed and developed?
- Where can I find pricing for a KATANA licence?
- Why is there no trial or rental option for KATANA on the webpage?
- How does KATANA's user interface work?
- Does KATANA come with its own renderer?
- Does KATANA come with its own shaders?
- Which renderers can I use with KATANA?
- Can KATANA be used for CG Features as well as VFX?
- How can I use KATANA for look development and lighting?
- What can these filters do?
- How can I integrate KATANA into an existing pipeline?
- How can KATANA deal with scenes of potentially unlimited complexity?
- What 3D data formats can KATANA read?
- How is data from Look Development, such as material bindings, handled in KATANA?
- How can I set standards such as image resolutions and anti-aliasing settings for different render passes?
- How can I share data between shots?
- Can I use KATANA for other output processes than rendering?
- Can I customize KATANA, such as using Python scripting?
- Can I write a new filter as a plug-in?
- Where can I find more technical information about KATANA?
KATANA is a 3D application specifically designed for the needs of look development and lighting in an asset based pipeline. Essentially KATANA is a system that allows you to define what you want to render using filters that can create and modify 3D scene data.
KATANA's user interface is designed to be the primary application for artists to use for all their 3D look development and lighting needs. KATANA also provides a rich set of more technical tools for power users and TDs and pipeline integrators.
System Requirements:
- Katana is tested and qualified on Linux 64-bit CentOS/RHEL 5.4
- A graphics card which supports OpenGL shader model 4
- A supported renderer (see below)
Supported Renderers:
- PRMan 16.4
- Arnold 3.3.13.0
- Arnold 4.0.1.0
The supplied renderer plug-ins are compiled and tested against these versions. Minor version increments of PRMan and Arnold may work, as long as they are API compliant with the supported versions.
To use a version of PRMan or Arnold other than those listed above, you may need to recompile the renderer plug-in.
To expose new features and portions, you may need to modify the renderer plug-in.
Using a version of PRMan or Arnold other than those listed above may produce unexpected behavior. Please note that we can only guarantee to respond to Katana bug reports when they are reproducible with the supplied versions of the renderer plug-in.
KATANA is production proven on over 20 shows since 2004 at Sony Pictures Imageworks, however it's not your standard boxed product and requires integration with your current workflow. To discuss your requirements please contact sales@thefoundry.co.uk, or register your interest by completing our online KATANA Site Survey.
Initially KATANA will only be supported on 64-bit Linux. The official qualified version of Linux is CentOS/RHEL 5.4 .
We are looking into adding support for other operating systems in the future.
KATANA was designed and developed in-house at Sony Pictures Imageworks, starting in 2004, as no commercial solution offered the scalable asset based workflows required by high end production. Over the next 5 years it was used on over 20 shows, and in 2009 The Foundry elected to share technologies with Sony Pictures Imageworks, in order to bring KATANA to to the wider post production community.
For more information, read the press release:
KATANA pricing is bespoke to each customer dependent upon requirements, please contact sales@thefoundry.co.uk to discuss your requirements.
Due to the unique nature of KATANA we will not be offering trial or rental options online. To discuss your requirements please contact sales@thefoundry.co.uk.
The KATANA user interface has a natural node-based approach, in many ways appearing similar to node-based compositing packages such as NUKE. Nodes are used to specify assets (such as Alembic files) the user wants to bring in, what filters the user want to use, output nodes for renders, and any dependencies between renders.
No. If you want to use Pixar's RenderMan or Arnold with KATANA you need to already have them as standalone renderers.
In KATANA 1.1 we aren't providing our own shader library, so you will have to provide your own shaders or shaders that come with the renderers. This is in line with the needs of most large VFX and CG Feature animation companies that have their own extensive shader libraries. We will be looking to provide our own shaders at some point in the future.
Currently Pixar's Photorealistic RenderMan (16.x) and Arnold (3.3.x and 4.0.x) are the two officially supported renderers. We are working on supporting some additional renderers.
At its core KATANA is a very renderer agnostic solution, and can potentially work with any shader based renderer. There is a plug-in API to integrate new renderers in KATANA, so companies can also use KATANA with their own proprietary renderers.
Very much so. KATANA was originally created by Sony Pictures Imageworks where it has been used for both CG Feature and VFX productions since 2004.
KATANA is a very flexible system that allows productions to work in different ways. For CG Features it is more common to have templates that every shot starts with to work to show standards. In VFX there tend to be a lot more one-off 'money shots' that want to be individually customized.
KATANA has filter functions that allow all the classic operations usually done in look development and lighting, such as:
- Creating instances of shaders
- Assigning shaders to objects
- Creating lights
- Moving lights around
- Changing visibility flags on objects
- Defining different passes that we want to render
The user is presented with a node-based interface that provides a natural way of specifying recipes of what filters to use.
- Bringing 3D scene data in from disk, such as from an Alembic geometry cache or camera animation data.
- Creating a new instance of a material such as a RenderMan or Arnold shader.
- Create cameras and lights.
- Manipulate the transforms of cameras, lights and other objects.
- Use rule based expressions to set what materials are assigned to which objects.
- Isolate parts of the scene for different render passes.
- Merge together the scene components from a number of different partial scenes.
- Specify what outputs (such as RenderMan AOVs) you want to use to render multiple-passes in a single renderer.
- Use python scripting to specify arbitrary manipulation of attributes at any location in the scene hierarchy.
A rich set of APIs are provided with KATANA to integrate with existing pipelines. In particular there are APIs to integrate render farm and asset management systems into KATANA.
The principle here is that we don't need to load all the scene data to light it. In KATANA , we are creating the recipe that will allow the scene data to be generated rather than directly authoring the scene data itself. It is only the renderer that needs to be able to see all the scene data, and only when it needs it. In KATANA we provide access to any part of the scene data to the user if the user needs to work on it, such as to set an override deep in the hierarchy or examine what attribute values are getting set, but the user can work by only having a small subset of the whole scene data open at a time. This is the key to how KATANA can deal with scenes of potentially unlimited complexity.
We recommend using Alembic, the open source format for geometry caching and 3D data interchange from ILM and Sony Picture Imageworks, as it's almost ideally designed to work with KATANA. In particular Alembic is very efficient at delivering data as it is requested on-demand, which works ideally with KATANA's approach.
There is also a C++ API to write your own 'Scenegraph Generators' which can be used to bring in data if you have an in-house data format for geometry cache files.
KATANA has its own format called 'Look Files' to hold data such as what materials to use on an asset and which material may need to be bound to any particular piece of geometry. In Look Development you bake out Look Files that represent the materials and assignments that need to be applied to the 'naked' asset, and in lighting Look Files can be assigned to assets to re-apply that data.
If the lighter needs to they can override what is set in the Look File, such as to do shot specific modifications to materials.
KATANA Look Files can also be used to hold data such as show and shot standards for image resolutions and anti-aliasing settings for different render passes, along with other data such as what output channels (AOVs) to use and any renderer specific settings such as PRMan shading rates.
As well as traditional 'Macros' to allow users to wrap up a number of nodes into a single one, KATANA allows you to also create 'Live Groups' to share nodes between different shots. Essentially a Live Group is a dynamically created macro to create nodes in KATANA, so if the macro is updated every scene that references it will get the update too.
Yes. The output of KATANA's filters is simply 3D scene data in a per-frame iterable form. This can potentially be used for other output processes.
KATANA is designed to be a very configurable system, with support for Python and PyQt. Python can be used in a number of ways including:
- scripting the creation of nodes
- set expressions on node parameters
- create 'SuperTools' that wrap a number of other nodes into a single one with a customizable interface. (For Nuke users these are similar to Nuke's Gizmos)
- create 'AttributeScripts' using python to directly modify attributes at render time.
Two C++ APIs are provided to create new KATANA filters:
The Scenegraph Generator API, to create filters that create new scene graph data. For RenderMan users these can be seen as KATANA's equivalent of RenderMan procedurals. Examples uses include:
- bringing in data from custom geometry cache formats.
- creating geometry procedurally at render-time, such as for crowd systems or debris.
The Attribute Modifier API, to modify attributes on existing locations in the scene graph. For RenderMan users these can be seen as similar to RenderMan riFilters. Example uses include:
- specifying textures to use on a piece of geometry
- modifying material assignments
- overriding shader values
- adding arbitrary meta data
A technical perspective of KATANA is given in The KATANA White Paper and KATANA Technical Guide.
- Read the KATANA White Paper
- Download the KATANA Technical Guide