how can I add "spare" parameters to an existing node

[mrice]

How does one add and organize parameters that arent part of a node's definition?

The only methods I can find require a "dialog script" stream, not sure how to go about that with the DS classes or if that's barking up the wrong tree.

Thanks in advance for any Guidance and hand-holding

[Marc]

Use the gear icon to add more parameters. You can basically just drag and drop as many as you like up there.

M

[edward]

How does one add and organize parameters that arent part of a node's definition?

The only methods I can find require a "dialog script" stream, not sure how to go about that with the DS classes or if that's barking up the wrong tree.

Thanks in advance for any Guidance and hand-holding

If you're talking about the HDK, then there are some higher level functions in OP_Director.h (and MOT_Director.h). I hesitate to point them out though because the interface there is messy and you won't hear me talk about this again.

[Marc]

oh duh! I didn't see what forum we were in. Well, close enough .

M

[mrice]

I should have added with the HDK

If you're talking about the HDK, then there are some higher level functions in OP_Director.h (and MOT_Director.h). I hesitate to point them out though because the interface there is messy and you won't hear me talk about this again.

but WAIT, before you never speak of this again:

OPgetDirector()->addNodeSpareParm(op_node, &myTemplate);

does indeed create a spare parameter, but it automagically puts it in a "spare" folder (pre H9 style? before my time).

I thought maybe I could get use PI_EditScriptedParms to reorganize it into the base parm layout, but I cant get that to work. Surely there must be a better way though? How does hou.Node.addSpareParmTuple() work?

Thank you!

[edward]

With lots of complicated code. If you can't use the simple interface in OP_Director, then I recommend you just do it by calling HOM from C++. There's a small example on how to call HOM from C++ in the HDK under HOM/SOP_HOMWave.C

[mrice]

I'll take a look at that, thanks for your insight.

[mrice]

The combination of using HOM to create a parameter, then OP_Director and PI_EditScriptedParms to change it as needed seems to be working great

One of the problems I was having was that I wasnt calling OP_Parameters::disableParmsAndSpareParms() before using OP_Director.

[edward]

That's odd. Which function in OP_Director were you using? As far as I can tell, disableParmsAndSpareParms() seems like it's already being called at end of addNodeSpareParm(), as well as from HOM_Node::addSpareParmTuple().

[mrice]

That's odd. Which function in OP_Director were you using? As far as I can tell, disableParmsAndSpareParms() seems like it's already being called at end of addNodeSpareParm(), as well as from HOM_Node::addSpareParmTuple().

You're right, If I create a parm through HOM_Node then no need for disableParmsAndSpareParms(). But if I use OP_Director::changeNodeSpareParms() to modify a spare parm created via python in the scene, the node's "parameter mixing layout" gets trashed without disableParmsAndSpareParms(). It would be nice if there was some information on how the parameter layout works, but I guess that's where "with lots of complicated code" comes into play? OK count me out.

Anyways, my revelation of the week is how nice the interface between python and the HDK is, very powerful stuff. Several things that have been tripping me up with the HOM are history!

[edward]

From my end of things it looks like everything is implemented on top of changeNodeSpareParms() which itself is implemented on top of changeSpareParms(). changeSpareParms() is actually where the real work takes place and that calls disableParmsAndSpareParms() at the end. But oh well, it doesn't really hurt to call it again.

[mrice]

Well I've run into one more problem with this.

I need a function that will destroy a given spare parameter and its containing group.

extract:

PI_EditScriptedParms spareParms = PI_EditScriptedParms(op_node, 1, 0);

int parmIdx = spareParms.getParmIndexWithName(parmName);
int groupStartIdx = spareParms.getParentGroupParm(parmIdx);
int groupEndIdx = spareParms.getMatchingGroupParm(groupStartIdx);

spareParms.removeParms(groupStartIdx, groupEndIdx-1);
mot->changeNodeSpareParms(op_node, spareParms, errors);

In general it works, but Houdini will crash when the parameter folder is on the boundry of a tab group. It might crash if its the first tab or else the last tab, one or the other, but the behavior is consistent. What's really strange to me is that just deleting the parameters and not the folders causes the same thing to happen.

A stack trace says that the crash is happening on PRM_Parm::setMostRecentCallbackValue(). Any idea when that gets called and what might be going wrong?

[edward]

Try removing the -1 part from "groupEndIdx-1".

[mrice]

Try removing the -1 part from "groupEndIdx-1".

Tried that, as well as anything else I could think of. The reason I have groupEndIdx-1 is because in the header it says that a group parm's opposite end will be automatically removed, so I thought that could be causing a problem. But what's strange is that even if I remove groupStartIdx+1, groupEndIdx-2 it still crashes, so it would seem this is not related to the switcher structure? But it only happens if the folder is on a tab group boundry

[mrice]

I narrowed it down to an issue with nested groups in the group I'm removing.

[edward]

Sorry, no idea then. I already warned that this was complicated. Maybe you could try calling dump() or save() and look to see if anything in the internal structure looks wrong.

[mrice]

Maybe you could try calling dump() or save() and look to see if anything in the internal structure looks wrong.

That's what I did. The ds stream is definitely getting messed up before Houdini crashes, but I really don't see why.

It didn't take long though while looking at the output to realize that the key to all this dynamic ui stuff was staring right at me:

1. get ds stream in python via C API

2. add,remove,modify,shuffle with python's Text Processing Power

3. send ds script back to the HDK and replace

4. drink beverage of choice while thinking about all the fun stuff this can be used for

So far this works great

[mitya]

With lots of complicated code. If you can't use the simple interface in OP_Director, then I recommend you just do it by calling HOM from C++. There's a small example on how to call HOM from C++ in the HDK under HOM/SOP_HOMWave.C

Anyway. Can anybody share sample, how to create parameters on existing node using only C++, as hou.Node.addSpareParmTuple() does?

Edited December 3, 2009 by mitya

[mrice]

Anyway. Can anybody share sample, how to create parameters on existing node using only C++, as hou.Node.addSpareParmTuple() does?

A bit simplified and probably dangerous:

void
SomeKindOfNode::addSpareParm(const PRM_Template *spareParmTemplate, const char *folderName)
{
	UT_String 		errors;
	OP_Director  		*director = OPgetDirector();
	PI_EditScriptedParms	nodeParms(this, 1, 0);

	const PI_EditScriptedParms 	spareParms(this, spareParmTemplate, 1, 0, 0);
	nodeParms.mergeParms(spareParms);

	if (folderName) {
		int folderIdx = nodeParms.getParmIndexWithName(folderName);
		if (folderIdx) {
			int folderEndIdx = nodeParms.getMatchingGroupParm(folderIdx);
			int myParmIdx = nodeParms.getNParms() - 1;
			nodeParms.moveParms(myParmIdx, myParmIdx, folderEndIdx - myParmIdx);
		}
	}

	director->changeNodeSpareParms(this, nodeParms, errors);
}

Or use HOM_Node::addSpareParmTuple() in the HDK as Edward says above.

Or get the ds stream, for example by passing an ostringstream object into PI_EditScriptedParms::save(), parse it, and you can really mess things up

[mitya]

Thanks, exactly what is needed!