TECHNICAL PAPER Building Tools for Houdini 9

More documents

Recommendations

Info

the section Distribution with Explicit Paths below to set the appropriate environments up.If you plan on releasing these to a wider audience (Side Effects Exchange), then you will need to duplicatethem and place these external dependent files within your $HIP environment in the proper sub-directories.The FX Tools are an example of this approach. When you install the tools from the shelf exchange installer,shared .otl files are also included in the package and are installed along side the tool Digital Assets.Distribution with Local PathsThere are two methods to distribute your tool(s): Using the passive Local Path approach used for internal developmentset up on the tester machines or a more formal Explicit Path approach described below. The LocalPath approach of distribution is recommended for testing purposes and for project specific cases. It is a fairlyloose way of working and encourages experimentation and development. For wider distribution and usagewithin a facility, managing your Houdini environments with Explicit Paths is mandatory. This method offers agreat deal of control and encourages proper versioning and release strategies to a wider audience.This method of distribution duplicates the same approach as the Internal Development process above. Youwill create local job directories and use the $HIP approach and all the appropriate sub-folders and files.There is much duplication of the tools. This has pros and cons. The pros is that you have local copies of yourassets and any global changes are not directly inherited. Manually copying in later versions of files and toolsis the way that versioning and upgrades are managed. Very secure. The downside is that you do not immediatelyinherit changes. Consider this a manual version control system.Distribution with Explicit PathsOnce tools have been developed and tested from $HOME/houdini9.0/toolbar they can be made accessiblefacility wide via the $HOUDINI_TOOLBAR_PATH, $HOUDINI_OTL_PATH and other environment variables.This method is used where you want the tools to be accessed site-wide or project wide. It allows users toinstantly inherit changes made to the tools.This method allows you to store the various files in very specific locations in the facility. This usually requiresworking with shells or setting system or user environment variables (windows). It requires an understandingof creating and managing system environment variables and knowing the various Houdini data types and theassociated environment variables to manage them. If you are the tool developer, then understanding the datatypes is assumed. Learning to create and mange environment variables is beyond the scope of this document.See Appendix E for references on managing system environments.The common major components of a tool consist of a .shelf file, an .otl file containing the digital asset(s),python scripts, python modules, and any other components. Any referenced images and geometry files shouldbe injected in to the digital assets saved in the .otl files to simplify the distribution and use of the tool(s). Allthe various components have their corresponding environment variables to manage them within the Houdinienvironment.$HOUDINI_PATH can be used as a way to manage tools. You can append the Local Path used for developingthe tool or a duplicated version to the $HOUDINI_PATH. This will include the tools in the current environment.If you are using a bash shell, it is done like this:export HOUDINI_PATH=$HOUDINI_PATH:/mnt/tools/my_toolwhere /mnt/tools/my_tool is the path to the root directory containing the tool(s) and all the related data thatyou wish to distribute to the site. This will append the path to the existing $HOUDINI_PATH environment variable.This line can be inserted directly in to the installed Houdini houdini_setup file for both bash and c-shellusers.Let’s take a look at the more common major parts of a Tool and the environment variables that are used tomanage them within the Houdini environment.HOUDINI_PATH environment variable to manage the environment22 | TECHNICAL PAPER Rev 1.0
It is best to not include the development path but to physically copy the development directory and all it’s subcomponentsto a more centralized location and include that in the $HOUDINI_PATH. This allows you to continuedeveloping the tools incrementing the versions as necessary and then bumping versions when required.Path Management with Discrete Environment Variables:Digital Assets and OTL’s: HOUDINI_OTL_PATHAs of Houdini 9 the use of OPlibrary files is not recommended to manage .otl files. The new method is toreference .otl files through $HOUDINI_OTL_PATH. Using this environment variable allows you to place the.otl files containing the Digital Assets anywhere on the file system. You do not have to locate these directoriesinside a formal passive houdini sub-directory. This gives you a lot of freedom to put these .otl files anywhereon the file system. This goes for any of the subsequent discrete environment variables below.The default location of .otl files within a houdini directory is a local ./otls directory.Toolbars and .shelf Files: HOUDINI_TOOLBAR_PATHAll .shelf files are managed with the environment variable HOUDINI_TOOLBAR_PATH.The default location of .shelf files within a houdini directory is a local ./toolbar directory.Shaders and VEX Tools: HOUDINI_OTL_PATHAll shaders and vex files are managed as digital assets contained in .otl library files. See theHOUDINI_OTL_PATH section above to manage these.Scripts: HOUDINI_SCRIPT_PATHAll hscript .cmd scripts are referenced with HOUDINI_SCRIPT_PATH.It is good practice to embed any local scripts inside the Digital Asset either as a section file or in one of themany creation scripts available in the Edit Operator Type Properties editor. Only use external scripts wheremore than one component of your tool(s) use the same script.The default location of .cmd hscript files within a houdini directory is a local /scripts directory.Python Modules: HOUDINI_SCRIPT_PATH/pythonWhen you import a Python module, Houdini will look in $HOUDINI_SCRIPT_PATH/python for the appropriatemodule. This is a subset of Scripts. You need to explicitly create a local python directory inside thescript path and place all your .py Python modules in there for Houdini to pick them up.It is good practice to embed any python modules inside the Digital Asset using the Edit Operator Type Propertieseditor. Only use external Python modules where more than one component of your tool(s) use the samemodule functions.The default location of .py Python module files within a houdini directory is a local /scripts/python directory.HDK dso’s: HOUDINI_DSO_PATHAll dso’s are referenced with the environment variable HOUDINI_DSO_PATH.The default location of .so (linux) or .dll (Windows) files within a houdini directory is a local ./dso directory.To get a full listing of the various environment variables and the houdini components that they manage, referBuilding Tools for Houdini 9 | 23
Page 1 and 2: TECHNICAL PAPERBuilding Tools for H
Page 3 and 4: Scripts: HOUDINI_SCRIPT_PATH 23Pyth
Page 5 and 6: 2.What are Tools and how are they u
Page 7 and 8: inside it. If Create in Context is
Page 9 and 10: ▪ ▪ Name is the internal name o
Page 11 and 12: 4.Steps to Develop a ToolIn this se
Page 13 and 14: 5.Designing Tools for Wider Distrib
Page 15 and 16: Parameters Folder3.The Gear Menu al
Page 17: 0003 active_pane = toolutils.active
Page 20 and 21: equivalent Python commands hou.Node
Page 24 and 25: to the Houdini on-line help.Distrib
Page 26 and 27: Componentsand lighting will have to
Page 28 and 29: Appendix B: Help Card Format with W
Page 30 and 31: Use heading 3s to represent paramet
Page 32 and 33: Examplehelp URLOBJSOPPOPDOPPOPCOP2t
Page 34 and 35: Components Description:FILE - is th
Page 36 and 37: Appendix E: ReferencesLearning Pyth
Page 38: Side Effects SoftwareProduction Con

TECHNICAL PAPER Building Tools for Houdini 9

Create successful ePaper yourself

Delete template?

Save as template?