Katana 2.6 Series
Katana 2.6v1 New Features
Viewer API
Katana now includes an API for creating 3D viewers with support for integrating (custom) 3D graphics technology with Katana's user interface. This API is being used by Foundry to develop a new built-in 3D viewer, which is scheduled to ship in a future Katana release. Customers can use the Viewer API to integrate their own viewer technology into Katana, should they wish to do so. Please consult the accompanying KATANA Viewer API: Getting Started Guide for a technical overview of the new Viewer API.
Note: Foundry anticipates the Viewer API available in KATANA 2.6v1 will be subject to minor revisions in 2.6 v-releases before it stabilises and ships alongside a new built-in Viewer in a future KATANA version. Customers integrating their own Viewer technology at this stage should be prepared to re-compile their Viewer plug-ins against subsequent KATANA 2.6 v-releases.
Viewer Manipulator Interaction Improvements
Viewers based on the new Viewer API benefit from a mechanism that protects against out-of-date location events while using a manipulator (typically seen as geometry switching back and forth between new and old transforms). The Viewer API suspends processing of Geolib location events during manipulation, and until any resulting node graph change is processed.
NOTE: While in Manual 3D Update Mode, following a manipulation, viewer updates are suspended until the user triggers a manual update.
Runtime Changes
-
FnGeolib.GeolibRuntime.commit() now returns an integer commit ID. Additionally, a runtime's most recent commit ID can be obtained using the new method, FnGeolib.GeolibRuntime.getLatestCommitId().
-
As soon as a Geolib3 Runtime transaction is committed, all calls to FnGeolib.GeolibRuntime.Client.getLocationEvents() are now guaranteed to produce only location events that are up to date with the committed changes.
- The return value of FnGeolib.LocationEvent.isLocationDataCurrent() was dependent on arbitrary circumstances at the point at which the location event was retrieved, and so provided no reliable information. This method is now deprecated and returns False in all circumstances, and shall be removed in a future release. To determine at any point in time if the location data provided by the most recent location event for a specific location is known to be current for the most recent Geolib3 Runtime commit, use the new FnGeolib.GeolibRuntime.Client.isLocationDataCurrent(locationPath) method.
- The method takes an optional commitId argument that can be used to specify an earlier commit ID. The default of -1 indicates that the latest commit ID should be used. If specified, the method returns True if location data is known to be current for, or more recent than, the given commit ID.
- This method is useful for determining if the runtime is done computing an active location, but getLocationEvents() did not produce a location event for it because the location has not changed.
Nodes3DAPI Changes
-
Nodes3DAPI.ManualUpdate() is now a legacy alias of the newly added Nodes3DAPI.CommitChanges().
- It is now possible to register for a single-shot callback when pending node graph changes are committed to Geolib3 for processing, by calling Nodes3DAPI.RegisterCommitIdCallback(commitIdCallback). The callback is issued with a commit ID as its only argument, which may be zero, indicating that no changes were committed (either because no node graph changes were pending, or because the changes did produce a commit ID).
Documentation Improvements
-
The Online Help's Environment Variables topic has been moved to the Developer Guide. Variables are now categorised, and read-only variables (such as KATANA_RELEASE) are distinguished from user-configurable variables.
-
Content from the Online Help's NodegraphAPI topic has been integrated into the Developer Guide. This brings together descriptions, examples and API references.
-
The API reference for Parameter objects has been split into sections covering different parameter types and use cases.
-
TP 240791 - The first part of developer documentation for widget types has been added to the Developer Guide.
-
TP 126093 / BZ 51296 - Documentation of .args files has been moved to the Developer Guide and substantially expanded. The documentation includes a description of the overall format, an XML schema, a listing of widget types and their supported hints, and usage notes for shaders, procedurals and GenericAssign.