Marc Posted December 1, 2004 Share Posted December 1, 2004 Hi all. ok so my first foray into building a real hda with all the bells and whistles has run into a few snags, and I thought it would be great to get some discussion going as to what can be made better... either with the hda's or my thinking . Here are my thoughts... If the contents of the hda are locked, then you cannot actually change any parameter inside the hda unless that parameter is channel referencing the dialog scripts parameters. Right off the bat, this seems a little limiting in what can be achieved, since ch()/chs() doesn't have the greatest flexibility. It seems to me that by design hda's are meant to be locked. So the poor hapless maya user that's using it can't go in and dick around with your beautiful networks. right? Maybe I've missed the mark on this. The reason you cannot opparm the networks contents, is because they all have read and execute permissions only. I think it would be cool if the dialog of the network acted as some sort of 'super user' and was able to override any permissions settings inside the network. That way people still couldn't go in and screw with stuff, but I'd have access via the dialog script to do all my fancy trickery and scripting that I wanted to do. Like I say, I'm really new to the inner workings of these things, so I could be trying to put the cart before the horse. I'm hoping someone could enlighten me if such is true. M Quote Link to comment Share on other sites More sharing options...
michael Posted December 2, 2004 Share Posted December 2, 2004 one thing you could do within the way hda's are now is to promote all the things you think you'll be needing to monkey with in the future and set the param to 'invisible' that way the Maya user will never see it but you'll be able to access it through hscript. all your talk about 'first forays into hda's' reminds me of about a year ago Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 2, 2004 Share Posted December 2, 2004 Hey Marc, what is it you are trying to do exactly? Most stuff is possible, I find I only really hit trouble when I want to add an edit sop. Using switch sops is often a good tip for getting around using opparm, for display at least. You are right about keeping stuff locked if you can, not only does it stop people messing with your networks but it keeps the hip files small and is way more efficient on memory. Quote Link to comment Share on other sites More sharing options...
Marc Posted December 2, 2004 Author Share Posted December 2, 2004 Hey Simon Well the few things I've run into so far that I would like to opparm are : 1. A render button in a ROP 2. A reload button on a File SOP 3. Display/bypass SOPs. I know the switch can be used, but I'd much rather be able to set the display to the SOP I want, same with bypass/unbypass. I know a few guys who need some of these things on their HDA's, but they have ended up just leaving the networks unlocked to get around it. I'm a little more outspoken than they are . BTW, I've ended up leaving mine unlocked for these very reasons (mainly 1 and 2). M Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 2, 2004 Share Posted December 2, 2004 For 1 and 2, use the plus button next to "create new" in the type properties box and navigate to the rop render button you need to add. This will set up a link automatically for you. For 3, sorry has to be switch sops. They aren't so bad once you get used to them, especially if you add a menu to the parameter you use to control the switch. Quote Link to comment Share on other sites More sharing options...
Marc Posted December 2, 2004 Author Share Posted December 2, 2004 Yeah, I tried the little plus button... didn't work for me. Perhaps its because my render node is actually an hda in itself (it runs all sorts of scripts to publish the data into our database). I still think a wonderful world of goodness would be opened if we could opparm stuff... I'll try again though, you never know. M Quote Link to comment Share on other sites More sharing options...
michael Posted December 2, 2004 Share Posted December 2, 2004 1. A render button in a ROP opparm myROPnet execute ( '!!ch("../someParam")!!' ) trange ( off ) f ( 1 300 1 ) 2. A reload button on a File SOP opparm -C /obj/geo1/file1 reload (1) 3. Display/bypass SOPs. switch sop...it's the only way (says kenny ) Quote Link to comment Share on other sites More sharing options...
Marc Posted December 2, 2004 Author Share Posted December 2, 2004 1. A render button in a ROPopparm myROPnet execute ( '!!ch("../someParam")!!' ) trange ( off ) f ( 1 300 1 ) What is ../someParam referencing? The name of the dialog script parameter? 2. A reload button on a File SOPopparm -C /obj/geo1/file1 reload (1) ok, that seems to work. Thanks 3. Display/bypass SOPs.switch sop...it's the only way (says kenny smile.gif ) Does this seem like a black art to anyone else? I mean, that render button opparm line is pretty obscure. It doesn't seem to be documented anywhere. In fact, the documentation for opparm states that the line should be this : opparm -c /out/mantra1 execute Which is pretty misleading IMO. Also, the two buttons which one would most want to use have two entirely different commands to make them work. Seems a little confusing to me. I feel like a total newb.... what a sucky feeling. M Quote Link to comment Share on other sites More sharing options...
Jason Posted December 3, 2004 Share Posted December 3, 2004 Yeah, I tried the little plus button... didn't work for me. Perhaps its because my render node is actually an hda in itself (it runs all sorts of scripts to publish the data into our database).I still think a wonderful world of goodness would be opened if we could opparm stuff... I'll try again though, you never know. M 15292[/snapback] The problem with opparming is then you may ask - why not opwiring? What happens if you upgrade to a later version of the same OTL - should it remember what you've opparmed? Will it still make sense? What if the inputs to the operator have changed - or the outputs are not compatable with the opparm-overriden values anymore? Think of the netowrk as a piece of code and the top-level parameters as an interface and you'll come to terms with it. Thats how I did it:) Quote Link to comment Share on other sites More sharing options...
Marc Posted December 3, 2004 Author Share Posted December 3, 2004 The problem with opparming is then you may ask - why not opwiring? What happens if you upgrade to a later version of the same OTL - should it remember what you've opparmed? Will it still make sense? What if the inputs to the operator have changed - or the outputs are not compatable with the opparm-overriden values anymore?Think of the netowrk as a piece of code and the top-level parameters as an interface and you'll come to terms with it. Thats how I did it:) 15301[/snapback] You see problems where others see solutions.... you'll never get anywhere with that attitude . hehe... alright, you may have a slight point. But is it so wrong for me to demand a consistent interface when dealing with things (ie. those buttons)? And how about opset? Nothing untoward about that... merely bypassing and unbypassing, displaying and ....er... undisplaying. M Quote Link to comment Share on other sites More sharing options...
Jason Posted December 3, 2004 Share Posted December 3, 2004 You see problems where others see solutions.... you'll never get anywhere with that attitude . hehe... alright, you may have a slight point. But is it so wrong for me to demand a consistent interface when dealing with things (ie. those buttons)? And how about opset? Nothing untoward about that... merely bypassing and unbypassing, displaying and ....er... undisplaying. M 15302[/snapback] Au contraire, my dear - I totally agree with you:) I wish that all widgets - toggles and buttons could have associated channels. Then you could key a button press or toggle. Instead there is that "special case" stuff that goes on - what with the !!ch()!! stuff that kinda breaks the model. I wish to God that SESI could do this, but I wouldn't be surprised if Houdini is so far down the road that it'll never be able to support it. I'd love to hear SideFx's opinion on channels for buttons, toggles and - dare I say it - strings! Quote Link to comment Share on other sites More sharing options...
sibarrick Posted December 3, 2004 Share Posted December 3, 2004 How ironic, I've just been stuffed by this myself. Trying to get round the fact that you can't lock an op in a locked network ( this makes sense of course) So I'm writing a chop channel out to disk then using a file chop to read it back in, but there's no reload button on a chop file op!!!! arrrgh. The way round it would be to bypass then unbypass but you can only do that in an unlocked hda..... doh! Quote Link to comment Share on other sites More sharing options...
Jason Posted December 3, 2004 Share Posted December 3, 2004 How ironic, I've just been stuffed by this myself. Trying to get round the fact that you can't lock an op in a locked network ( this makes sense of course) So I'm writing a chop channel out to disk then using a file chop to read it back in, but there's no reload button on a chop file op!!!! arrrgh. The way round it would be to bypass then unbypass but you can only do that in an unlocked hda..... doh! 15312[/snapback] can you try an "opcook -F"? one technique is to have 3 HDA, two inside one and one of those two being unlocked by default. the sops in the locked one contain the rigid system and the the sops in the unlocked is a "play area". ie.- a structure like this: /obj/master_hda /obj/master_hda/system_area /obj/master_hda/dynamic_area ..using ObjectMergeSOP, you can loop out of the system_area into the dynamic_area where anything goes, Quote Link to comment Share on other sites More sharing options...
Marc Posted December 3, 2004 Author Share Posted December 3, 2004 I was thinking of saving it as 'unlocked' but then going in and changing the permissions to r-xr-xr-x myself. Then any parameter I wanted to change, I could quickly give it write permissions, do what I want to it and then change it back. That way people can't mess with it, but I still have access. Of course, it doesn't help with the less memory side of things of using a locked network. Cheers M p.S. I still don't know exactly what this is doing : opparm myROPnet execute ( '!!ch("../someParam")!!' ) trange ( off ) f ( 1 300 1 ) Specifically the !!(ch..)!! part. Anyone care to point me to some docs or something? Quote Link to comment Share on other sites More sharing options...
Jason Posted December 3, 2004 Share Posted December 3, 2004 This thread makes me think that - would it be nice if there was some special type of Subnet operator that you could put inside of locked HDAs which were unlocked? The contents of these could remain constant when the rest of the OTL is changed. SESI? Quote Link to comment Share on other sites More sharing options...
michael Posted December 3, 2004 Share Posted December 3, 2004 nope...it doesn't make sense to have a locked hda that has 'unlocked' stuff inside... the "code/params as interface" analogy is a really great one. to lock a node is to change the very sructure of the hda - the data flow is now locked at that point - this is better handled with switches and injected sections. as for opparm myROPnet execute ( '!!ch("../someParam")!!' ) trange ( off ) f ( 1 300 1 ) here is an eg. file rendetrMe.tar.gz Quote Link to comment Share on other sites More sharing options...
Marc Posted December 3, 2004 Author Share Posted December 3, 2004 I understand why they did it, I just don't necessarily agree with all of it. Here's one example. In my hda there is a little network that groups primitives. I've presented a choice to the user where its either grouped randomly, or they can select the prims they want grouped. In a perfect world I could opparm the settings in one group SOP and be done with the whole thing. Right now I need to have two group SOPs piped into a switch, and the switch is linked to a pulldown menu in the dialog script. It just seems a little redundant, thats all. But hey, if that's the way it is, then that's the way it is. I still think the button's inteface needs to be cleaned up alot. M P.S. In the example file, the button doesn't do anything and there's no callback in the dialog editor. Is there supposed to be something there? Quote Link to comment Share on other sites More sharing options...
Marc Posted December 3, 2004 Author Share Posted December 3, 2004 urk... actually it does do something. Still don't see anything in the parameter editor though.. Quote Link to comment Share on other sites More sharing options...
michael Posted December 3, 2004 Share Posted December 3, 2004 when you press the button the execute parameter becomes (1) - and does it's thing, in this case render the twist sop to disk...there isn't a need for anything else... btw... you can key a menu thingy...I'd avoid it though - funky things can happen...we have a param on our characters that allows the user to choose between a few different display types...it got a channel one day and an animator had 'key on param change' on...LOL...whenever he scrubbed his timline the character would change from proxy to low-res to off to low-res etc etc...it was hilarious Quote Link to comment Share on other sites More sharing options...
Marc Posted December 3, 2004 Author Share Posted December 3, 2004 So did you use the little plus button to add it to your dialog? If so then that doesn't help me. I tried that and it didn't do anything, not even an error.... nada, zilch. poo M Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.