| On this page |
New
Houdini 20.0 uses the new license system. Previously this was a feature that could be enabled. Moving forward this system is the only system available.
Warning
This system requires hserver to be Houdini 19 or above and a sesinetd of 18.5 or above. Also not all options, behaviors, and environment variables are available in this system. Either they are not needed anymore or can be done via a better method/workflow.
The license products are ordered based on a hierarchy. The hierarchy is based on the financial cost and features available for that product (i.e. FX > Core > Engine). The system works based on a list of lists. Each sub list represents a license mode (Commercial, Education, Indie, Non Commercial). The order of the lists also tells hserver which are more important and which are less important (the first sublist being the most important). The order of the sublists are [Commercial, Education, Indie, Non Commercial].
[ [Engine, Core, FX], [Engine EDU, EDU], [Engine Indie, Indie], [Apprentice] ]
License Mode |
License List |
|---|---|
Commercial |
Engine, Core, FX |
Education |
Engine EDU, EDU |
Indie |
Engine Indie, Indie |
Apprentice |
Apprentice |
In this example the list of lists can be transformed into [Engine, Core, FX, Engine EDU, EDU, Engine Indie, Indie, Apprentice] as another way of thinking about the license checkout order. If we take a closer look at the Commercial mode list for hython we have [Engine, Core, FX]. Engine is listed first because its the best license type that suits the application and it also happens to be the cheapest so most customers will want to use up all of these licenses before trying Core or FX. Since FX is the most expensive and isnt exactly meant for hython but can be used to run hython its placed last as most customers will only want to use this as a last resort. Each list within the main list is for each of the license modes and the items within that list are the individual licenses order by their hierarchies based on the application.
Scenario that can take advantage of this system flexible design:
If a studio has multiple projects with some artists working on show A, some on show B, and some working between the two. Lets say show A can never use FX licenses for any applications. A simple launch script could be created for show A to skip FX licenses by adding --skip-licenses="Houdini-Master" to the command line or environment for any application that is launched with the launch script. System admins don’t need to manage environment variables, hservers, or any other applications. Instead, they can create launch scripts that are checked into versioning control systems that manage the shows desired license behavior. This allows admins to update the license behavior, push it to the VCS, and the next time the artist updates they will have the new license behavior.
The process of enabling or disabling specific licenses for an application is referred to as product overrides. Product overrides can be changed studio wide or directly from an artists machine. To edit your product overrides open hkey and navigate to File ▸ Partition Licenses and select the Product Overrides tab.
The process of applying product overrides is first the studio overrides and then the artist overrides (both are optional). This means that the artists overrides will replace whatever options the product overrides the studio has set. As an example, lets say for product houdini the studio has skipped Houdini-Master licenses but the artist has selected Houdini-Master licenses. The result would be Core and FX licenses being checked. If the artist did not override the studio settings then only Core would be checked.
Note
You can list any license type to check or disable but it will have no effect if the product doesnt use that license. For example, you can add --check-license=Karma-Render for the app houdini but it will have no effect as houdini cannot run off a karma license.
Product Exchanging ¶
Product exchanging is the process of exchanging one license for a lesser or more important license based on the list of lists for the applications requesting licenses. An example of product exchanging:
-
Houdini Core is opened. Checks out a Core license.
-
Houdini FX is opened. Checks out an FX license. The core license is returned and the Houdini Core application is running off of the FX license.
-
Houdini FX is closed. A Core license is checked out and the FX license is returned. The Core application is now running off of the Core license.
Command line options ¶
Note
All command line options here apply to the application and not to hserver.
--list-license-checks
With all of these options its important to be able to view the list of licenses that the application will try to ask for. This option will have the application print out the list of lists used to request a license from hserver. If an entry has a - character in front of it that means its currently being omitted from the request to hserver. To enable a license to be checked add its internal name to --check-licenses. To disable a license from being checked add its internal name to --skip-licenses.
--check-licenses
Some applications may have extra licenses that it can check but may not be checked by default. In the case of Houdini Core, it does not check Houdini FX licenses and with --check-licenses="Houdini-Master" Houdini Core will turn on checking Houdini FX. To add extra licenses to check add ',' between license names.
Note
Some applications cannot checkout specific licenses regardless of this option. For example, Houdini FX cannot checkout a Houdini Engine license.
Tip
If running Houdini Core and Houdini FX at the same time is common its recommended to add --check-licenses="Houdini-Master" to Houdini Core environment variable. See below for details.
--skip-licenses
With some setups it might be desired to skip certain licenses for a number of different reasons. A studio might reserve FX licenses for specific roles or projects and might want everyone else to use Core in the meantime. In some cases it might make sense that an artist never wants to grab a Houdini Non Commercial license. With this option specific licenses can be skipped. The syntax for this option is --skip-licenses="Houdini-Non-Commercial" with , being the separator between license names.
--skip-license-modes
This option allows entire license categories to be skipped when requesting a license. This option can be handy when a user does not want to checkout a non-commercial license. commercial, education, indie, and apprentice are the available options.
--check-license-modes
This option is only useful if a license mode needs to be reverted from a previous --skip-license-modes option. This has the same options available as --skip-license-modes.
Environment variables ¶
Since this system uses the application to dictate the license behavior each application has its own environment variable for adding application wide license options. When a set of licensing behaviors is desired for all applications of a specific type (i.e. Houdini Core) the applications license environment variable can be used. The contents of these environment variables is the exact same as the command line options for the application. As an example if every Houdini Core should check for Houdini FX licenses then environment variable would be HOUDINI_CORE_LIC_OPT="--check-licenses=Houdini-Master".
Tip
The environment variable for the application is processed and then the command line options are processed. When the command line options get processed it may overwrite any options used in the environment variable.
Environment Name |
Applications |
|---|---|
HOUDINI_LIC_OPT |
Houdini |
HOUDINI_CORE_LIC_OPT |
Houdini Core |
HOUDINI_FX_LIC_OPT |
Houdini FX |
HOUDINI_INDIE_LIC_OPT |
Houdini Indie |
HOUDINI_NC_LIC_OPT |
Houdini Apprentice |
HOUDINI_EXPER_LIC_OPT |
Houdini Experimental |
HOUDINI_PDG_LIC_OPT |
PilotPDG |
HOUDINI_HYTHON_LIC_OPT |
Hython and Hbatch |
HOUDINI_MANTRA_LIC_OPT |
Mantra |
HOUDINI_KARMA_LIC_OPT |
Karma |
HOUDINI_MPLAY_LIC_OPT |
Mplay |
HOUDINI_PLUGIN_LIC_OPT |
All Supported Plugins (i.e. Unity, Unreal, Maya, etc). |
When an application is started under this system the application specific license environment variable is checked and then the command line options are checked. For example if Houdini Core is launched the HOUDINI_CORE_LIC_OPT environment variable is checked and then the command line options are checked for license options.
Guide to moving to Houdini 19 Licensing System ¶
Note
Since these two systems are fundamentally different this guide is only a guide to give an approximately similar behavior in licensing and should not be taken as a way to get the exact licensing behavior from the previous system.
With the new features and change in how this system works there are some items that you should be aware of prior to switching over to this system. The biggest change is all previously existing licensing environment variables and options have been deprecated with this release in favor of the options provided by this new system. Since this system is a fundamental change in how an application can control its licensing it is not possible to change the licensing system at runtime and can only be selected at startup.
Warning
All previously existing licensing options (i.e. environment variables) have been deprecated in this release and will be fully removed in the next release.
The tables below give a rough guide for converting some environment variable values over to Houdini 19 licensing. Some values have been omitted as they no longer apply with this new system.
HOUDINI_SCRIPT_LICENSE |
Houdini 19 Environment Options |
|---|---|
hbatch -R |
Add |
PDG_LICENSE_MODE |
Houdini 19 Environment Options |
pdg_only |
No action should be taken as this just uses the existing pdg license list when the application uses one (i.e. PilotPDG). |
engine_only |
Add |
houdini_core_only |
Add |
houdini_fx_only |
Add |
Houdini command line |
Houdini 19 Options |
-apprentice |
Add |
-indie |
Add |
-core |
Add |
Houdini 19 licensing goes from hserver and a complex network of environment variables controlling behavior to the application deciding the full list of licenses that it should be allowed to use. As such hserver options --relax-non-graphical/-g and --render-only/-n are no longer used with this system. These options can still be set for applications using the old system but will simply be ignored for this system as they are not necessary as the application controls the licensing behavior for Houdini 19 licensing.
Houdini 19 licensing uses HTTP(S) exclusively and will make NO no attempt at providing any backwards compatibility in behavior of the old system or in communication protocol with the old system. Hserver is able to run using both systems at the same time but upgrading/downgrading will be disabled as hserver is unable to make a decision on what to do as older systems will not provide the necessary information.