[Sidefx-houdini-list] disappearing HDA parameters

Jim Callahan callahan at temerity.us
Mon Jun 9 15:57:22 EDT 2008


I agree Paul, but there should be nothing scary about a full fledged 
system... ;^]  In fact, I think its vital.

As mentioned by Sean Lewkiw way back in this thread I created a system 
at Weta about 7-8 years ago using a combination of CVS and Makefiles to 
manage VEX and the OPlibrary files external to Houdini which worked very 
nicely within that limit context, but failed when it came to relating to 
the rest of the production.  Since Houdini is always going to be part of 
a studios overall production pipeline solution, I'd think most would 
want to have the choice of how to do this within the context of all 
applications at the studio not just their main or even secondary DCC 
tool.  If anything, I think studios are become even more heterogeneous 
when it comes to the variety of tools they use and more complex in how 
they use them together.   I wouldn't underestimate the importance of 
understanding dependencies across the entire production process.  I 
don't think revision control of just OTL/HDA's would be sufficient to 
solve this problem by itself no matter how sophisticated it was 
implemented within Houdini.

Contrary to conventional wisdom on the subject, I think this is just as 
important for smaller studios with short deadlines and very small team 
sizes.  Even one person can create a lot of complexity which can get out 
of control without version control and dependency analysis.   They also 
are just as liberal, maybe even more so, when it comes to used a mixture 
of different tools.  A one solution model isn't going to do it for small 
studios either...

Just so you know, Temerity Pipeline is platform agnostic.   We handle 
portability between Linux, Mac OS X and Windows as well as between 
user's private "sandboxes" in a CVS-like style as part of our version 
control.  I see managing OTL/HDA versions as an issue of managing the 
contents of files which don't change names and therefore all references 
to these files remain constant.   I think this is exactly the same issue 
faced by Maya users with referenced scenes.   The only serious problem 
with using Maya references is managing how updates flow through the 
production.  Maya didn't need to provide any kind of version control 
system as long as something does externally.   From Maya or Houdini's 
perspective nothing has changed in terms of how these external resources 
are referenced, only that their contents have changed.

When Maya referencing first came out (even now for some studios) it was 
viewed as dangerous because when you use it without version control all 
hell can break loose.  The problem wasn't anything Maya needed to fix 
really, just how studios chose to use referencing.  IMO, Houdini's 
OTL/HDA's are already much more sophisticated. 

Jim Callahan - President - Temerity Software <www.temerity.us>


paul simpson wrote:
> some excellent points here.  it's funny to see that the conversation quickly
> veers into a fully fledged asset tracking/management system though - which i
> think is scary.  fwiw, i would rather this exist outside houdini's realm.
>
> back to (my) main point: i can't emphasise enough the need for "houdini
> digital assets" (aka OTL's) to have proper package management (read:
> versioning, dependencies, packaging).  i agree that there's no need for sesi
> to write this from scratch if they can lever external (and platform
> agnostic) tools.  why is platform agnositc important (being a die hard linux
> user?) because i want some windoze user to be able to export there new uber
> rig to the houdini exchange and everyone to be able to download it and run
> it without having to worry about what other HDA's are used within said
> uber-rig.
>
> this is different (and a subset) of proper cvs/subversion tools.  ie, the
> difference between yum/zypper/deb tools and subversion/cvs.  the former
> allows us to keep our HDA's under contorl - the latter - whole
> shots/jobs/projects aligned...
>
> now, how do we all reach some kind of simple consensus and hopefully give
> sesi a clear message what we all need?  i would really love to see this in
> the next major version (and have been asking for 5+ years)  ;-)
>   


-- 




More information about the Sidefx-houdini-list mailing list