Take and takes: part 1 — What and Why.

Takes in Houdini are an extremely powerful and flexible way to nondestructively try different parameter values in the same session, create render passes for lighting, and create and compare variations. In the series of posts on FauxLiner, we looked at reasons and ways to combine and wrap hscript with hython.  The takes libraries is more elaborate but is done in a similar fashion and for similar reasons.

The takes system is currently accessible from hscript but not hython.  As takes is so powerful and versatile, it is often needed from python, particularly as larger pipeline and tool scripts move to hython. This often results in wrapping hscript take commands in similar looking python code. For example,we can  look at a simple take related command, takename  This can easily be wrapped in pyton, making an equivalent accessible in HOM for take renaming.

Docs Usage example shows:
takename take new_name

# this can easily be python wrapped as
def takename(take, new_name):

hscript_cmd = ‘takename ‘ + take + ‘ ‘ + new_name
hou.hscript(hscript_cmd)

return None

And this is done and done often. It is very common to redevelope or rebuild similar scripts and tool utilities again and again at different jobs or in different projects. Wouldn’t it be easier to have all these common wrapped Houdini take related commands available in a python library while awaiting the official hython takes release ? — the presented python modules attempt to do just that.

This is a ‘stop-gap solution’. Lets briefly go over what is typically meant by this. In short, there is a time lag or a ‘gap’ between what is needed (in this case python access to Takes) and what is available (the official hython release by sidefx is not in current builds). We need to ‘stop’ the gap with an implementation or ‘solution’. Stop-gap solutions aren’t usually elegant and often rely on brute force (we could have this library pull from the HDK C++ libraries which would be more efficient and flexible, but sidefx should eventually be distributing this, so we avoid al ot of extra work by taking a efficiency hit by wrapping hscript). Stop-gaps are intended to be temporary measures and come in two basic varieties: The first is a branch of a tool, project or pipeline that “does the job” and when the gap is passed will be completely discarded as the proper released solution moves into the main fork. The second type moves inline with the tool, pipe, or project and is intended “to transition” to the final solution, which then in itself will be transitioned to from the stop-gap solution. The second variety tends to get employed when the time frame for the final solution is long, unknown, or of unknown stability/compatibility. The Takes solution presented in these posts is of the latter variety.

The first decision that was needed is whether or not to present the wrapped hscript takes commands in a similar 1:1 fashion as shown with takename above. For those who already know hscript, it would be very easy to guess the py equivalent. But wait… When looking in the Houdini docs it would appear there are already some indications on how this may be implemented, if we look at hou.takes and hou.Take. These two docs have what appear a fairly complete list of functions to deal with takes, what methods the Take object will eventually employ, and what kind of values we can expect to be returned by the functions and class methods. Although the docs lack any real description of use, some assumptions can be made by drawing parallels with what is already known about the hscript implementation. The function naming is also descriptive and provide insights. i.e. It can be assumed that…

hou.Take.addParm(self, node)

…will eventually add a parameter to the take that this instance of hou.Take represents. Because we have access to the mentioned information on the possible eventual sidefx implentation, this library models itself after it, and NOT a 1:1 hscript wrapper. This provides additional advantages…

  • forward compatibility (easy upgrade path): by keeping the function names and return values in sync with what we expect the official hython release to be we ease upgrading. Ideally it would be as simple as finding all “eyevex.takes.Take” and replacing them with “hou.Take”, but in reality its not likely going to be THAT easy.  We can avoid introducing additional problems by resisting the temptation to ‘improve’ on the functions and args presented in the docs with changes, and keeping such enhancements in a separate module which can continue to be used, even after the official release.
  • full advantage of pythons object oriented features: when the rest to tools using the library are taking advantage of hython OOP features it could be awkward to deal with the separate procedural style of straight python wrapped hscript
  • reduced breaking changes if the ‘gap’ lasts longer than anticipated: since it is unknown when the official implementation will arrive, there remains the possibility this could fall into long term or indefinite use. Especially considering the library will be distributed, by keeping the function names and return as close as possible with the docs, all the function bodies in between can change. The initial inefficiencies in a quick stop-gap solution that are acceptable may become cumbersome in long term use. This allows the function bodies to be rewritten for greater efficiency or even pull form HDK level (if for some reason this became worth while) without having to alter any code utilizing the modules.

Continue to the next section for download information, as well as potential differences between the presented modules and what will eventually ship in the hou module with Houdini.

Leave a Reply

Your email address will not be published. Required fields are marked *