HDAModule.setParmTemplateGroup() wiping out parm defaults

   4560   8   1
User Avatar
Member
59 posts
Joined: April 2006
Offline
I am trying to write a script for a button that adds a parameter (actually, a copy of a parm from another node) to an (unlocked) OTL definition, and it works except that the call to setParmTemplateGroup() is not only adding the new parm, but clearing out the default values in parm definitions already on the OTL. My code is basically this:

otlDef = otlNode.type().definition()
parmLayout = otlDef.parmTemplateGroup()
newParm = srcNode.parm('creature_name').parmTemplate().clone()
parmLayout.append(newParm)
otlDef.setParmTemplateGroup(parmLayout)
In this case, the OTL that is getting the new parm added happens to also have a number of frame range (int array) parms with default values (expressions) of $FSTART, $FEND. The call to setParmTemplateGroup() clears these default expressions out of their parm definitions and sets them to 0. Could anyone explain why this happens and how I can avoid it?
User Avatar
Member
59 posts
Joined: April 2006
Offline
Okay, maybe a better question is this: where do the default parm values/expressions get stored in hou.ParmTemplate objects? You would think it would be in the default_value tuple, but apparently not.

Example:

Suppose I add an Integer parm to my OTL called fps. I go to the Channels tab in the Parameter Description section of the Type Properties dialog and set its default value to the expression $FPS. When I click Accept, I see the new parm on the node that is an instance of my OTL and it has $FPS as its default expression/value.

However, if I run the following python code to interrogate the ParmTemplates on this OTL, I see that the default_value tuple for the fps parm is (0,):
parmLayout = node.type().definition().parmTemplateGroup()
for parmTemplate in parmLayout.entries():
print parmTemplate

The printed form of the fps ParmTemplate is this:
<hou.IntParmTemplate name='fps' label='FPS' length=1 naming_scheme=Base1 default_value0,)>

So where is the fact that $FPS is the default expression for the fps parm being stored? Clearly it must be stored somewhere in the OTL definition because it is set properly when I drop down a new instance of the OTL. And yet, if I change the parmTemplateGroup programatically (like if I add a new parm to it via the python code in my original post), the fact that $FPS is supposed to be the default expression for fps is cleared out somehow.

Surely someone knows what is going on here!
User Avatar
Member
59 posts
Joined: April 2006
Offline
Bump..
User Avatar
Member
59 posts
Joined: April 2006
Offline
Bump.
User Avatar
Member
696 posts
Joined: March 2009
Offline
Yeah, this is a bit confusing, but as far as I understand, whenever you set an expression to a parm, it becomes a keyframe, internally.
It seems that the edit parameter interface dialog does the same in the background, although we still have access to the expression as if it was a parameter default.
I created a parm through the GUI and add an expression as default and then I inspected the python code to generate that node and it returns the same as you already found (default_value0,)) which kinda makes sense since the parameter is an int field, but then when it's time to set the expression it goes through a bunch of commands to generate a keyframe with the expression I wanted as a default… I haven't tested saving the code to file and using it to re-create my node, but would be the next step, I guess…
I wonder where is the hint that makes the edit parameter interface reverse engineer the keyframe expression back into a default value expression. Either that or the python code is not telling the whole truth!

Cheers
Toronto - ON
My Houdini playground [renderfarm.tumblr.com]
“As technology advances, the rendering time remains constant.”
User Avatar
Member
59 posts
Joined: April 2006
Offline
Well, if we look at the HDK side of this, we can see that PRM_Template objects store PRM_Default objects within them. Examining the documentation for the PRM_Default constructor reveals the following interesting bit of info:

PRM_Default:RM_Default (float thefloat = 0.0F,
const char * thestring = 0,
CH_StringMeaning string_meaning = CH_AUTO_DETECT_OLD_EXPRESSION
)
PRM_Default has two parts: a float and a string. For floating point parameters, if the default string is defined, then the parameter will start off being animated and have the channel expression defined by the string. Otherwise, the floating point default is used for float and integer types, while the string is used to initialize string types.
This conforms to the behavior you described. If we call PRM_Template::getDefault() on a PRM_Template object, we would expect to get back an object containing the expression string (e.g., “$FSTART”) that represents the default value. The real question is what is the python equivalent to this PRM_Default object, and how do we access it?
User Avatar
Member
696 posts
Joined: March 2009
Offline
Yeah, sorry about that useless comment… I was reading the docs and found a method setDefaultExpression and defaultExpression to respectively set and retrieve a ParmTemplate's default expressions.

http://www.sidefx.com/docs/houdini12.0/hom/hou/FloatParmTemplate#setDefaultExpression [sidefx.com]

I just don't understand why the asCode method doesn't use these methods.

Cheers
Toronto - ON
My Houdini playground [renderfarm.tumblr.com]
“As technology advances, the rendering time remains constant.”
User Avatar
Member
59 posts
Joined: April 2006
Offline
Ah, so this is a Houdini 12-only addition to the HOM. I should have known.

Thanks for pointing it out to me, though. Much appreciated.
User Avatar
Member
696 posts
Joined: March 2009
Offline
Also to me it only worked with build 665.
Toronto - ON
My Houdini playground [renderfarm.tumblr.com]
“As technology advances, the rendering time remains constant.”
  • Quick Links