Disableparms

[sibarrick]

Ok, my first dumb HDK question

What does the disableParms function do? And do you have to write one for all sops?

Where can I find more info about what should be in it?

Ok it's really 3 questions but whos counting

[edward]

It gets called to disable (or enable) parameters based on the value of other parameters. No. See any of the HDK SOP examples.

1 paragraph, 3 answers.

[sibarrick]

I kinda figured it was from the name, but in all the examples I can't see how they are doing it. But I guess if I don't want or need any disabling then I don't need to define this function, yes?

For instance in the BrushHairLen example it doesn't do anything

unsigned
SOP_BrushHairLen::disableParms()
{
    int  changed = 0;

    return changed;
}

In the flatten example

unsigned
SOP_Flatten::disableParms()
{
    unsigned changed = 0;

    changed  = enableParm(3, !DIRPOP());
    changed += enableParm(4,  DIRPOP());

    return changed;
}

Ok this seems to do something but how?

I assume

enableParm(3, !DIRPOP());

means enable parameter number 3? All parameters have an index? Does the second parameter mean enable or disable depending on it's value?

Is the enableParm function the only one you ever need within the disableParms function?

[sibarrick]

It's ok I found it under

OP_Parameters

in the doxygen listing

[Mario Marengo]

Hey Simon,

Let me see if I can help a little, though I warn you that I'm still very green with the HDK...

Both enableParm() and disableParms() come from "SOP_Node"'s distant parent "OP_Parameters". Your SOP derives from SOP_Node and so will inherit these two public members. However, disableParms() is virtual.

The purpose of the (concrete) member enableParm() is to enable/disable a given parameter. To do this it needs to know which parameter to enab/disab, and that's what you stipulate through its parameters -- more on those later. The point is that this is the function you must call in order to actually carry out any en/disabling.

The virtual member disableParms() gets called (I assume) whenever a parameter's value is changed (by the user, or on-load, etc). Houdini takes care of *when* it gets called, not you. But this function is not "pure virtual", meaning that it has a default implementation (which does nothing) in it's original class (OP_Parameters). Point is, it is "optional", but if you *do* need to enab/disab parms in your SOP, you should implement it, in which case your version will get used (by virtue of it being virtual and all ). So now that you've decided you need to implement it, what the heck do you put inside it? Well, among other things, calls to enableParm() presumably, since that's your only interface to do any actual en/disabling. But whatever you do in there, disableParms() should return zero if no change was made (nothing got enabled which was disabled or viseversa) and >0 otherwise (why it's unsigned and not bool beats me... maybe some arithmetic is being done with this return value).

int enableParm(int pi, int state, int v = -1);

You tell enableParm() which parm you want to en/disable by giving it the parameter's index (pi) , the state you want it to have (0=disabled, 1=enabled), and, optionally, a vector index (for vector types, though I've never checked if this actually en/disables, say, just the y-component if given a 1 as a vector index). The parameter index (pi) is simply the index into your "parameter template" array -- the one whose address you passed to table->addOperator() inside the static creator (dso entry point) newSopOperator().

That's all a parameter list is: an array of PRM_Template objects, and "pi" is just the index into that array. There's an optional version of enableParm() that takes a parameter's name instead of its index, but I'd imagine that would be slower (but useful if you know the name but not the index, natch).

... I'm trying to achieve that ultimate 3-line response, but I'm failing miserably here

Hope that helps,

Cheers!

[sibarrick]

Hell once your not green anymore there won't be enough space on the web

As ever thanks for the extra level of insight, I'm happy enough to guess at these things and get the thing working but it's easier when it's all in context and you know for definate you have the whole picture.

3 line responses are good too though, gets the job done 'n all.

Look out for more dumb questions soon, I'm about to start compiling. If I don't try it for real all this reading is going to make my head explode.

What ever happened to 3 line programs.

10 print "hello"
20 goto 10
30 print "you'll never know this was a 3 line program"

[Jason]

10 print "hello"
20 goto 10
30 print "you'll never know this was a 3 line program"

19164[/snapback]

And in Chinese:

[sibarrick]

I bet even Mario would have a hard time with that one!

[edward]

There's an optional version of enableParm() that takes a parameter's name instead of its index, but I'd imagine that would be slower

19146[/snapback]

Thanks for the response I was too lazy to type, Mario.

As for using the index instead of a name, yes it's a tad faster but who really cares? The lookup is done via hash tables if you give it a name so it's not really that slow at all.

[hoknamahn]

What to do with t if evaluator is defined as

int PARM1(float t) { return evalInt("parm1", 0, t); }

is it normal to call it with 0 instead of t? I mean if you call evaluator as parameter of enableParm() inside disableParm...

Edited October 12, 2007 by hoknamahn

[edward]

Yeah, disableParms() hasn't been updated to use time. I would then use CHgetEvalTime() in that case.

[hoknamahn]

Cool! Btw when I have a choice which method of getting a time is faster - using of context.getTime() or CHgetEvalTime()? Is there any big difference? I know it doesn't matter until you use these functions in huge loops but anyway you would like to write the code as optimal as possible.

[edward]

I would recommend using context.getTime() whenever possible. I think it's usually the same as CHgetEvalTime() but in theory it might be different.

[hoknamahn]

Hey Edward,

Could you explain what I'm doing wrong?

My SOP has one parameter (call it "mode") and a switcher (with the name... "switcher") with other parameter inside it (say "parm").

I want to disable the "switcher" when "mode" == 0, enable "switcher" when mode == 1 and at the same time disable "parm". And enable "parm" when "mode" == 2.

I'm using this

unsigned changed = 0;

changed  = enableParm("switcher", MODE(getTime()));
changed += enableParm("parm", MODE(getTime()) > 1);

return changed;

But it gives me not exactly what I expect to see... When "mode" == 2 all things are enabled (both switcher and parameter). When "mode" == 1 "parameter" is disabled. "mode" == 0 disable "switcher".

Seems to be okay. But. When I change again "mode" to 1 I expect to see disabled "parm" but it is enabled! Okay I change "mode" to 2 and change again to 1. Voi la - "parm" is disabled... I suppose something wrong with changed += ...

Any ideas?

[edward]

Not offhand ... make sure MODE() is returning what you expect eg. print the values out inside disableParms().

[hoknamahn]

No Edward, even if I use this:

changed  = enableParm("switcher", MODE(getTime()));
changed += enableParm("parm", 0);

everytime when I enable a switcher "parm" (probably this is important: "parm" is placed inside a switcher) becomes enabled. So is it bug or I'm just using it in a wrong way?

[edward]

No idea then. You could try paring down the code to the bare essentials to demonstrate the problem and submit a bug (Support > Submit H9 bug at sidefx.com). Make sure you fully describe the problem and what you expect to see.