I really like Takes, and have used them in the last few jobs. Takes solves the problem of hip file branching which is a major pain, but there are a few drawbacks. The first drawback I'm going to go after is using Takes in multiple contexts. (The second part will deal with autotake).

Multiple Contexts:
Problem:
I find that when using takes you are pretty much limited to a single context. Ie). You have 7 different animation Takes, or you have 5 different lighting Takes or 12 different shading Takes. (Multi-context Takes are when you have 3 animation and 2 lighting Takes) When you start to have multiple takes in multiple contexts, Take management becomes a large hassle. Now at a large studio where you have a animation department, lighting department, etc, Takes are fine. But at the smaller shops where you generally have one hip file and you are actively changing animation, lighting and shading at the same time, Takes quickly becomes more trouble than its worth.

For example,

You have 3 Takes which define different variations of the model. (English, French and Albertan version)


hip
English
French
Albertan


Then your director can't make up his/her mind on how your model should move so you have 3 animation Takes.


hip
English
French
Albertan
Hop
Skip
Jump


And the art director is just as bad as the director and can't decide whether to go with the pastel or earth tones shading.


hip
English
French
Albertan
Hop
Skip
Jump
Pastel
Earthy


Now you have a meeting the next day where they will hover over your desk and want to see the different versions and make comments about them. So you stay up late setting up your Take list like the following


hip
English
eng_Hop
eng_Hop_Pastel
eng_Hop_Earthy
eng_Skip
eng_Skip_Pastel
eng_Skip_Earthy
eng_Jump
eng_Jump_Pastel
eng_Jump_Earthy
French
frn_Hop
frn_Hop_Pastel
frn_Hop_Earthy
frn_Skip
frn_Skip_Pastel
frn_Skip_Earthy
frn_Jump
frn_Jump_Pastel
frn_Jump_Earthy
Albertan
alb_Hop
alb_Hop_Pastel
alb_Hop_Earthy
alb_Skip
alb_Skip_Pastel
alb_Skip_Earthy
alb_Jump
alb_Jump_Pastel
alb_Jump_Earthy


Ok, first of all, typing that out took forever not to mention how long it takes to make a nice clean version in Houdini.

So the director and clients are breathing down your neck and they love how you can switch to the different versions real quick, but then the art director wants you to make the Earthy shading a little more red. Now what?

Having to back and adjust each *_*_Earthy Take would take forever…so you jump out the window. While you are falling to the ground you realize you could have changed them all pretty quickly with hscript. But having a hscript solution shouldn't be the only way to manage large number of Takes. *splat*

Possible Solutions:

Two possible solutions:

A- Have a method to allow symbolic linking in the Take list. That way I only have to manage one Earthy Take, and all the *_*_Earthy takes reference the base Earthy Take.


hip
English
*eng_Hop -> hip/Hop
*eng_Hop_Pastel -> hip/Pastel
*eng_Hop_Earthy -> hip/Earthy
*eng_Skip -> hip/Skip
*eng_Skip_Pastel -> hip/Pastel
*eng_Skip_Earthy -> hip/Earthy
*eng_Jump -> hip/Jump
*eng_Jump_Pastel -> hip/Pastel
*eng_Jump_Earthy -> hip/Earthy
French
*frn_Hop -> hip/Hop
*frn_Hop_Pastel -> hip/Pastel
*frn_Hop_Earthy -> hip/Earthy
*frn_Skip -> hip/Skip
*frn_Skip_Pastel -> hip/Pastel
*frn_Skip_Earthy -> hip/Earthy
*frn_Jump -> hip/Jump
*frn_Jump_Pastel -> hip/Pastel
*frn_Jump_Earthy -> hip/Earthy
Albertan
*alb_Hop -> hip/Hop
*alb_Hop_Pastel -> hip/Pastel
*alb_Hop_Earthy -> hip/Earthy
*alb_Skip -> hip/Skip
*alb_Skip_Pastel -> hip/Pastel
*alb_Skip_Earthy -> hip/Earthy
*alb_Jump -> hip/Jump
*alb_Jump_Pastel -> hip/Pastel
*alb_Jump_Earthy -> hip/Earthy
Earthy
Pastel
Hop
Skip
Jump


If your active take is set to one of these symbolic takes, and you want to make a change you could have a option to either
-modify the original take.
-symbolic takes are read only, can't edit them, you have to set your active take to the original.
-take no longer becomes symbolic and is just a copy.
-a child take is made.

That's the first option. Pretty simple, fits the existing scheme.

Second option is to ditch the Take List altogether and make Takes more node based.


Possible Take nodes could be Null, File, Merge, Take. When merging takes with matching parameters, the right hand most input takes ownership. (or what ever DOPs do).

In addition you could take advantage of display flags on Take Nodes. If a Take Node doesn't have its display flag turned on it won't show up in the list of active Takes.

Hey, nice one.

So, to summarise the “take drawback” another way - it's annoying to have to explicitly conjoin all the possible combinations (model+move+shading) into one selectable take.

Here's an idea: what if you could select multiple takes!? yes yes hold on! It's not as craazy as it sounds. The take interface would still be a tree, maybe like this:

hip
Model:
English
French
* Albertan
Move:
* Hop
Skip
Jump
Shade:
Pastel
* Earthy


let's call these mid level nodes: Take Switches.

You could then make independent choices for each of the three. Hmmm. Perhaps it's last night's drinks with the friendly DD-Folk clouden me thinken, but it seems the only problem would be if two sub-takes had conflicting values - one would have to win. (?) Maybe we could just say the last one wins (from top to bottom through the list).

Ah! But would there be conflicts? What if we took clever-wolfwood's idea about scoping (nb. his follow-up post on auto-takes) and applied scopes to the Take Switches (Model, Move, Shade). That might solve that, quite simply.

Perhaps the rule would be Take Switches must have a scope. And perhaps sibling switches cannot have overlapping scope.

cheers,
ben.

I like to see something to solve this problem too. We are still using groups to manage a heap of stuff that would be much better done in takes if only we could combine them.
At it's simplest perhaps as long as you got a warning about conflicts then it could be left to the user to arrange his/her takes so that conflicts were removed.

I dig Ben's idea.

In combination with scopes, the Take switches aren't really switches but Scope Groups.

I'm not sure I like the idea of Scope Groups/Takes Switches not being able to have a overlapping scope. Its sounds like a good restriction to prevent “stupid user” problems but at the same time it might be a pain if you want to create a quick scope to test something.

Must ponder some more.

Come'on people, more brainstorming.

I like your idea of sumbolic links too, it does at least mean you can see what combinations you are making, with take groups you'd have yet another level of abstraction to deal with…. I think it's one of those things that needs trying, very difficult to imagine which way works best in all the different scenarios.

But just to re-state it, I think the idea is definately a flyer! C'mon Sesi you know you want to

Simon
I like your idea of sumbolic links too, it does at least mean you can see what combinations you are making, with take groups you'd have yet another level of abstraction to deal with…. I think it's one of those things that needs trying, very difficult to imagine which way works best in all the different scenarios.

True. Personally the symlinks would fit my work style better than Take Switches as you only ever have One Take as output. But Ben's method looks like it will require less management. (No need to make symlinks everywhere).

That's why I want more people to add their comments because people use Takes in different ways. (Some people keep all their takes flat in hip. Others, like me, are huge inheritance monkeys.)

Jason, Goldfarb, Peter? Comments?

Well, I haven't had the opportunity to use Takes in H8 yet, so it's hard to tell. They were so horribly broken in 7 that we very quickly gave up and waited for 8. It appears that many of the problems have been fixed for 8, so I'm keen to try them again. They've always held a lot of promise, but still have fundamental problems that make me a bit wary.

Assuming you were using H7, I'm curious how you overcame the many problems in 7. Many of these are fixed in 8, btw, but it sounds like you ploughed ahead in 7.

1. Opchangetype on an OP removes that OP from all takes!
2. Reloading the dialog on a SHOP removes that SHOP from all takes!
3. You could not script Takes in 7 (the scripting commands were basically broken).
4. Takes broke VOPs, dead.
5. Files SOPs that used takes to control what was loaded using the $ACTIVETAKE would not recook properly.
6. Lack of any sort of Take spreadsheet, even read-only. This is still a problem in 8, btw. How do you see an overview of what is set in what take? Ideally, you'd want to be able to gang-modify settings across takes.

Anyways, personally, I'd rather see the fundamental issues resolved before diving into more esoteric upgrades, but that's just me )

Cheers,

Peter B

Ahh…good points Peter. I've only used Takes in 8 (over the summer), it seems I missed out on a lot of pain. :shock:

Thanks for fighting through it initially and getting the big bugs worked out.

As far as I can tell all the issues that you mentioned (not item 6.) seemed to be fixed in 8.

Having a Take Spreadsheet is also something that I'd really like. (I was going to mention it in the Auto Take post…but thought I had whined enough already).

But this should be “Fairly Easy” to add though. Replace the Take Contents window, (the thing on the right side of the Take List) and put the Parameter Spreadsheet there instead. It be the same Parameter Spreadsheet that Houdini already has, but it would filter out all the OPs and parameters that weren't part of the current take.

Hah, yes, I thought it would be easy too. Apparently it's almost impossible with the current architecture (

Of course, I could (and might) write my own in Javascript, so I'm not 100% buying it )

Cheers,

Peter B