I've been building a wrapper OTL for an internal shader Mario has written, and I'm pretty well done, but I have some questions.
Much of what I've needed to do is enter lots of channel expressions to have the functionality of a Houdini light play nicely with the top level interface. Betwen callback scripts and some expressions, I've got that working.
However, I stole an expression that I've been unable to find definitions for. They work, but I'm wondering if someone can tell me how to RTFM. If I want a channel in a node that lives deep in the bowels of the network to mimick the contents of another high above it, I've found that something like this works:
opparm foo bar_enable ( ‘!!ch(“../../../bar_enable”)!!’ )
Now this looks at the root level of the operator that I'm building, and steals the value of “bar_enable” and uses that. It works fine. What are the “!!”'s all about, though? What do they do?
Another question - this works well enough for integer/float/logic channels, but it doesn't work properly with strings, especially when there's a menu of string choices. So, I've found that:
opparm foo2 bar_list ( ‘`chs(“../../../bar_list”)`’ )
works just fine. However, I get one warning when I save the OTL that does *not* happen when I use the earlier expression:
“The selected node has references to nodes outside the subnet, or has references that are absolute path….”etc etc.
It lists this particular expression that it's unhappy with. It still saves just fine, and everything seems to work, but it's not very purty. Fact is, I'm *not* using an absolute path, nor am I referencing to outside of the node I'm building - that particular path I'm showing is at the top node level. In fact, it has to be, or this would break.
Is this just a broken warning in this context?
Thanks
J.C.
OTL scope and other questions
5165 3 0- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
- mtucker
- Staff
- 4517 posts
- Joined: July 2005
- Offline
The “!!ch()!!” syntax was introduced because we don't support channel references with some parameter types, and to allow the propogation of button presses, and do a couple of other things that OTLs needed to be able to do. It basically a way of doing a channel reference in a parameter that can't do channel references.
I am a bit curious about your assertion that this syntax works for float/integer parms though. Are you just assuming it work? Because it really should only work for string and “ordinal” parameters (buttons, check boxes, and some menus are “ordinals”, which is different from integer menus or animatable integer parameters).
I'm also concerned about your statement that this syntax does not work for string parameters. Could you provide a sample hip file/OTL where this doesn't work?
As for the warning, you are correct that it should not appear. Could you provide the specific text that appears after the parameter name in the warning dialog? Is it “Unable to resolve node”? Are you using the expression in an “Operator Path” type parameter?
Also, what version of Houdini are you using?
Thanks,
Mark
I am a bit curious about your assertion that this syntax works for float/integer parms though. Are you just assuming it work? Because it really should only work for string and “ordinal” parameters (buttons, check boxes, and some menus are “ordinals”, which is different from integer menus or animatable integer parameters).
I'm also concerned about your statement that this syntax does not work for string parameters. Could you provide a sample hip file/OTL where this doesn't work?
As for the warning, you are correct that it should not appear. Could you provide the specific text that appears after the parameter name in the warning dialog? Is it “Unable to resolve node”? Are you using the expression in an “Operator Path” type parameter?
Also, what version of Houdini are you using?
Thanks,
Mark
- JColdrick
- Member
- 4140 posts
- Joined: July 2005
- Offline
The “!!ch()!!” syntax was introduced because we don't support channel references with some parameter types…
Gotcha.
I am a bit curious about your assertion that this syntax works for float/integer parms though.
My mistake. Nope - I didn't use it for scalars - only toggles, menus, etc…
I'm also concerned about your statement that this syntax does not work for string parameters.
This is probably about me getting my syntax wrong with all the different types floating out there. What I needed to use the “chs()” for, and what didn't work with “!!” was the popup requestors that put in the path to a node. For instance, the light/transform/lookat button. When I pointed the “!!” format to that type of param, it didn't work. I plugged in the chs() and it worked fine, barring the warning when I saved the OTL.
Could you provide the specific text that appears after the parameter name in the warning dialog? Is it “Unable to resolve node”? Are you using the expression in an “Operator Path” type parameter?
Unable to resolve node. And I suspect that the param you describe is indeed the “lookat object” type param I mentioned earlier.
Just to clarify - it *works* - it just bitches. Although if this isn't kosher I guess I better know now in case it gets busted in a future version…
I'm currently running 6.0.333
Thanks Mark…
J.C.
John Coldrick
- mtucker
- Staff
- 4517 posts
- Joined: July 2005
- Offline
JColdrick
This is probably about me getting my syntax wrong with all the different types floating out there. What I needed to use the “chs()” for, and what didn't work with “!!” was the popup requestors that put in the path to a node. For instance, the light/transform/lookat button. When I pointed the “!!” format to that type of param, it didn't work. I plugged in the chs() and it worked fine, barring the warning when I saved the OTL.
Hmm. The “!!” syntax should work for these types of parameters. It's possible there was a problem with them that has been fixed in 6.1 (I can't replicate any problems). There may also have been problems if you had multiple layers of referencing (/obj/foo/bar/stuff referenced /obj/foo/bar, which reference /obj/foo). If you see this problem again, please post or email me the hip file so I can have a look. But in any case if the chs() approach is working for you, stick with that.
Unable to resolve node. And I suspect that the param you describe is indeed the “lookat object” type param I mentioned earlier.
Just to clarify - it *works* - it just bitches. Although if this isn't kosher I guess I better know now in case it gets busted in a future version…
Yes, what you are doing is perfectly valid, and you can count on it continuing to sork in the future. There is no good reason for Houdini to be bitching. I've fixed this for 6.1.
Thanks for the bugs,
Mark
-
- Quick Links