HDA's discussion

[michael]

nope...

I just made a button then opparm'ed the ribOutpu node like this in a textport:

opparm . execute ( '!!ch("../someParam")!!' )

where "../someParam" is the path to the top level button

the ' (that's the one near theright hand enter key) protects the !!ch...!!

[Marc]

oooooooooooooooooooooooooooooooooooooohhh....

Now I get it.

...

.....

.

Holy crap thats obscure!!!11!!!!1!!one!!1!!!!one

Just when you thought it was starting to get user friendly, then they throw a curveball. I'll give it a try and let you know how it goes.

M

[sibarrick]

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?

15318[/snapback]

I agree with this, I asked for it almost as soon as I started playing with hda's when they were still in beta but nobody seemed to understand what I was on about or why I needed it...... The way I see it you could easily do this by storing the contents of the unlocked subnet in the hip file and have a link that says "this locked hda has this unlocked subnet in it, get the data for this from the hip file" .

I guess it would be something like using a dynamic include structure, if you want a programming analogy. Not sure if you can have a dynamic include in programming...... something like the precompiler options for vex though. Where you can have if and include options.

So if the hda foo is instance 29, include unlocked data 29 from the current hip file.

Anyway I live in hope that this will be implimented in some way some time in the future.

[michael]

marc >

welcome to the brave new world...there are dozens of really obscure things going on with OTLs and none of them are documented...

sibarrick >

hip file?!? what is that?....

if you push the use of OTLs far enough you don't need hip files...I don't think I've saved a file in months (other than to continue working after lunch or whatever)...

the idea of having an unlocked hda or an hda with 'dynamic' stuff inside is a bad one I think...it can cause huge problems....if the shot is just a one off or if the hda doesn't need to be a shot wide asset then you can get away with it, but it doesn't scale at all - 100's of OTLs (with 100s of versions) that contain dozens of dependent OTLs...keeping track of things becomes a nightmare...not to mention the imposibility of troubleshooting problems...

however, sometimes we have unlocked hda(s) inside a locked hda:

myThing.otl (locked)

>mySubThing01.otl (locked)

>mySubThing02.otl (unlocked) - where you have unlocked it to make some change specific to the shot etc

if you want to draw data from disk into a locked hda just use a file sop(etc) with a promoted param to tell it where to get the stuff, that way you can change the stuff an just need to change the top level param and not have to unlock the hda.

...ps..

there used to be a bug where you could opchange stuff on a locked hda...but Ed 'fixed it'

[sibarrick]

can you try an "opcook -F"?

15315[/snapback]

Nice idea, I'll try that

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,

15315[/snapback]

That's what I usually do too. Gets real messy real quickly though.

[sibarrick]

Sure it's a bad idea if you don't use hip files but we do, and would have no problem with it. I'm just suggesting that rather than having to have the entire hda unlocked you just unlock the non-procedural parts. It's the same as saying make locked and unlock versions that link together, it's just a heck of a lot easier to manage from a user point of view.

For example I have a system for building procedural trees say, but you what the modeller to go in and tweak the point positions that control where all the branches are. Sure I could link a handle to every point but that isn't very flexible, and what if you want more points? Ok so you have to have a locked asset and an unlocked one. In the unlocked one you object merge in all the bits you want to be worked on non-procedurally, but for the modeller that's a nightmare because you completely loose the flow of want you are working on, you have to be constantly checking where the merge comes from if you want to see where it lives in context. It's like saying to an animator all the handles for animating a character all live at the origin, and don't move around with the character!! imagine that, and imagine telling the animator they have to be at the origin or it's a nightmare to manage all the transforms that put them where you want them.

I think the thing here is that I use them for modelling and maybe you are using them for lighting, effects, or whatever. If you use them for modelling every time you need to insert an edit sop or a sculpt or anything that is non procedural you have to add a whole extra hda to contain it. Now that gets to be a nightmare to keep track of . Every asset has to be chopped up into lots of little parts. Whereas if you could have an unlocked edit sop in a locked network then you could have as many user edits as you need and store them all in one asset, whilst at the same time you could maintain the structure of the network that the asset was built from.

I guess I'm probably using them for things they aren't designed for but they are so helpful it makes sense to use them where you can.

.if the shot is just a one off or if the hda doesn't need to be a shot wide asset then you can get away with it, but it doesn't scale at all - 100's of OTLs (with 100s of versions) that contain dozens of dependent OTLs...keeping track of things becomes a nightmare...not to mention the imposibility of troubleshooting problems...

This doesn't make any sense, if I need a shot wide asset that is 100% procedural I don't need the unlocked bits so it's not an issue, the problem is not all things can be solved procedurally. Hence the need for unlocked parts. Each time the unlocked part is changed it is changed for a specific reason and I don't want it turning up in the other instances of the asset, but I do want changes made to all the procedural parts to be referenced, I want the unlocked bits to be hip file specific. I keep track of them, 100 of them or 1000's by knowing what the hip file is for.

[edward]

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 

15325[/snapback]

I can't believe you guys left me out of this! Punishing me fixing the opchange bug I suppose.

For the record, I understood Simon's request way back when he talked about it the first time. You guys have no idea of the amount of RFEs we have or talked about and just said, "yes, it would be nice" . Back when OTL's were first designed, I also suggested a "template" idea. Instead of having it just parameterized by "parameters", having it parameterized by "nodes" as well. Then it makes the idea of doing "template rigs" much easier as one can then draw the skeleton and then apply these "template rigs" to add the rest of the controls.