Kanzi 4.1.1 release notes

Rendering

  • Reduced the memory that the OpenGL and Vulkan backends use for internal resource management.

  • The OpenGL render thread now sets its operating system thread name, so it appears as OpenGL Thread in debuggers, profilers, and thread listings. This matches the existing behavior of the Vulkan render thread.

  • In bindless rendering, Kanzi now applies material property values that you set on a node. When a node overrides a property of its material, Kanzi creates a separate GPU-side material entry for that node. The override does not affect other nodes that use the same material. To manage these entries in application code, use the GPUScene::registerMaterial, GPUScene::unregisterMaterial, and GPUScene::getMaterialIndex overloads that take the node that overrides the material.

Kanzi Studio

  • Kanzi Studio no longer keeps a referenced project in a directory that belongs to another project. When you open a project that references one stored inside another project’s directory, Kanzi Studio asks through the Move nested referenced projects dialog to move it out to a sibling directory, and updates every path that pointed into it. If you decline, Kanzi Studio does not open the project. You also can no longer add a project as a reference when it is stored inside another project’s directory.

    When the project that you add as a reference holds another project inside its own directory, Kanzi Studio asks the same question for that other project. If you decline there, Kanzi Studio keeps the project you have open and leaves only the project that you added unloaded.

    The move changes directories on disk and you cannot undo it, and it does not update the paths that point into a moved directory from outside Kanzi Studio, such as the ones in your build scripts.

    See Where to store a referenced project and Kanzi 4.1.1 migration guide.

  • Kanzi Studio no longer asks whether to continue when it finds more than one project file below the directory of the project you open. That question was there for projects stored inside another project’s directory, which Kanzi Studio now moves out to sibling directories instead of asking about. When the directory of the project you open holds more than one root project file, Kanzi Studio still cannot open it, and reports that when the load fails. See Project directory and Where to store a referenced project.

Platforms

  • On the platforms that load plugins dynamically, when your application uses the dynamic Kanzi Engine libraries, the Kanzi build now copies the Lua plugin to the application output directory together with the other Kanzi libraries. A deployed application no longer needs the Kanzi installation directory in the library search path to load a kzb file that uses Lua.

    See Deploying the Lua plugin.

  • Fixed the issue where Kanzi dropped touch inputs on QNX whenever the same touch point received multiple touch events during the same frame. (INTE-1288)

Android

  • The project templates now control the Lua plugin with the KANZI_LINK_KZLUA CMake option, in the same way as the other optional Kanzi Engine plugins. On Android, a Kanzi Engine plugin reaches the APK only when the application links it, so an Android project that uses Lua must enable this option in the kanzinative/build.gradle of the project. The Android configuration of the project templates enables it by default.

    See Deploying the Lua plugin.

Notable fixes

Kanzi Engine

  • Fixed the issue where a floating-point trace sample with a non-finite value (NaN or infinity) wrote an invalid JSON token into the trace file, corrupting it so that trace viewers such as Chrome tracing and Perfetto could not load the file. Kanzi now omits non-finite floating-point samples when it writes the trace file. (RENDERING-3096)

  • When Kanzi cannot load a Kanzi Engine plugin, the error now names the library file that it tried to open, includes the error that the dynamic loader reported (on Windows, its numeric error code), and states that the plugin library must be deployed with the application. Previously the error named only the plugin, which gave no indication that the library was missing from the application package. (ANDROID-2131)

  • Fixed the issue where a Property Target Interpolator or a Property Target Easing Interpolator prevented an application from entering the indefinite suspend state. Kanzi reported the interpolation as an ongoing animation for as long as the interpolator was attached, even after the interpolated property reached its target value and stopped changing. Because of this, a single interpolator anywhere in the node tree kept the application waking up at the frame rate, which increased the CPU load. Kanzi now reports an interpolation that reached its target as no longer ongoing, and reports it as ongoing again when you set a new value to the interpolated property. (FMW-1394)

    See Application idle state.

  • Fixed the issue where Kanzi ignored the Keep Alive Behavior property of material types. A material type that Kanzi loads from a kzb file honors the property again. Kanzi 4.1.0 introduced the issue. A freshly loaded material type always got “do not keep alive”, whatever the project set, so Kanzi released the shader program of that material type when the last user of the material type released it, and paid a shader compile the next time it used the material type. This happened when the application purged resources, and also when the application used the Optimize Memory strategy. When Kanzi re-created its graphics resources, for example after the graphics context was lost, it read the property from the wrong position and always got “keep alive” instead. Which of the two values a material type had therefore depended on whether the graphics context had been lost since Kanzi loaded it. The fix moves the kzb file format version from 45.0 to 45.1, so export your project again with this version of Kanzi Studio: Kanzi loads only the format version that it expects. (KANZIUX-841)

    See Kanzi 4.1.1 migration guide.

  • Fixed the issue where Kanzi Android Service terminated the service host process, and with it every client application, after the window of one client application lost its surface. This happened, for example, when you moved one client application to the background and then interacted with another client application. Kanzi Android Service kept the Kanzi view of the client application whose surface was gone in use, and using the surface of that window then terminated the process. Rebuild the client applications of a service host against the same version of Kanzi as the host. (ANDROID-2130)

Kanzi Studio

  • Fixed the issue where, in a multi-project solution with a subproject stored inside the main project’s directory, Kanzi Studio appeared to freeze when running Save All, could show the Project modified dialog, and could crash when saving subprojects. (FMW-1319)

  • Fixed the issue where the Kanzi installer did not include the Android Service application project template, so Kanzi Studio did not offer it and you could not create a Kanzi Android Service project. The installer now includes the template with both its host service and client applications. (ANDROID-2113)

  • Fixed the issue where Kanzi Studio failed to open a project with the error [NullGuard] applicationConfiguration is null. Kanzi Studio 4.1.0 introduced the issue. It occurred when the generated faces or roughness mipmaps of an image-based lighting cubemap texture were missing from disk. Kanzi Studio stores that generated content in directories that the default .gitignore excludes. Every fresh clone of an affected project therefore failed to open, while the project kept opening on the computer that created it. Kanzi Studio now regenerates the missing content from the source image. When Kanzi Studio cannot regenerate the content, it reports the reason in the Log window and opens the project. This happens, for example, when the source image is no longer in the project. (FMW-1355)

    Kanzi Studio now regenerates the content of all image-based lighting cubemap textures in a project in a single pass, so a project with several such textures opens faster.

    See Using version control systems with Kanzi and Using image-based lighting cubemap textures.

Rendering

Documentation

  • Fixed the issue where the Kanzi Engine C++ API reference documented loadShaderProgramCreateInfo with a signature that Kanzi does not build. The Kanzi 4.1.0 API reference showed the function taking both a ReadOnlyMemoryFile and a KzbMemoryParser, which is the signature of a code path that Kanzi compiles out, so a call written against that page does not link. The API reference now documents the signature that Kanzi exports. (DOC-1065)

See also

Kanzi 4.1.1 migration guide

Known issues