[Sidefx-houdini-list] unified cpio / hda production management systems

ken ken at corefa.com
Tue Oct 2 13:23:07 EDT 2007


I considering going the route of cpio for asset management last January 
as we were in the middle of redefining our system. (no longer SIAM, or 
SIAM II for those ex-WILD readers). I opted out of it for a number of 
reasons, first one being it was unclear and no one at SESI could tell me 
of the format (of a hip file after expansion) was going to change. 
Although you can reverse engineer how the structure is laid out and what 
the files do, with the changes going on with H9 I felt it was not safe 
to make a large commitment to that work. Also you miss out on some key 
information regarding OTLs (read HDAs) from a cpio expand... 
specifically what is an HDA or not. You do get a lot of 'neat' things 
but manipulating the data and migrating existing tools to work with the 
chn format would have made for a larger time hit.

Plus a lot of tools in hscript are removed from your toolkit so that was 
a drag, unless you are prepping files before and after expand/collapse.

The main attraction was finding a way to reuse the exist on copy/paste 
function by treating the .cpio generated by the copy as a hip file. You 
can do it if you know what to add to it and change the extension.. then 
you can merge the data like a hip file. FYI, if you try to use HDAs to 
contain work (nodes and hierarchy) and to expand them on creation you 
will pay a price in the time it takes. There are dependency checks (name 
clashing) that you can only avoid if the file is empty first, also at 
subnet expand or otl expand in session is treated as a copy the data 
inside, delete the subnet/OTL and then past the contents... thus giving 
you the name clashing issue, channel checking for references and the 
sort.. oh and if you do this at all... "undoctrl off" via the textport 
hscript command is your best friend... just be sure to turn it on again :)

It is a nice idea but cons out weighed the pros from my perspective. A52 
had such a system but I haven't heard much since they announced Maya was 
going to be added to their pipeline. 
http://features.cgsociety.org/story_custom.php?story_id=3478

We store the versions installed in the hipfile (of HDAs) and their 
animation, anything that isn't an HDA gets stored as well and its 
animation as well. Name clashing is always a problem but we are able to 
quickly rebuild a shot file via command line and workflow structure 
helps reducing borked results.

We are also playing with a more file-referenced method to keep updates 
more seamless, but that also has issues. (and no it isn't during renders 
as we convert the seamless reference to a locked version when renders 
hit the farm).

In the end, how you work will be debated and argued for a while. It 
really boils down to workflow..(what is the user doing with the HDA, and 
do you keep everything an HDA or do you allow for standard Houdini nodes 
to be used and if that is the case, how do you approach that one)

-k






Andrew D Lyons wrote:

>>I don't know exactly what is cpio, hexpand and hcollapse
>>    
>>
>
>For those that haven't seen it before, hexpand and hcollapse live in
>the $HFS/bin. They allow you to collapse a .hip file to a directory
>structure containing all hip data in exploded form. You can then
>modify that data within limits before re-collapsing them back into a
>regular single hip file.
>
>Many of us have found that for large shows where you want to share
>parm settings across multiple shots in a modular way, that hip files
>are less and less useful. In this pythonic age perhaps we'll see some
>new tools for storing and managing parm data across multiple shots?
>
>It's good to hear how others manage this hipscene/otlrig/otlparm asset
>hierarchy in the meantime though...
>
>Cheers
>
>
>On 02/10/2007, François Duchesneau <sidefx at trinix.ca> wrote:
>  
>
>>I don't know exactly what is cpio, hexpand and hcollapse but I used
>>Subversion for versioning Maya files and it worked with small files and
>>a few.
>>
>>For a future project in a rather "no tool" company I want to use
>>Subversion combined with some customization that would create a new
>>incremental version of assets and shots at each check in. I'm sure the
>>concept works but I'm curious to see how it reacts with tons of data
>>required in a production scenario.
>>
>>I'll have to simulate this before pushing this idea but if anyone has
>>any experience with Subversion, I'd be curious to see how it worked for you.
>>
>>François
>>
>>Rangi Sutton wrote:
>>    
>>
>>>Ammon Riley wrote:
>>>
>>>      
>>>
>>>>On 9/28/07, Andrew D Lyons <tstexture at gmail.com> wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>How many places have explored using the cpio capabilities of hexpand
>>>>>and hcollapse in conjunction with a revision control system to store
>>>>>hip data?
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>This was a topic that came up on the list back in early- to mid-2001.
>>>>I believe that Denis Gauthier (at A52, at the time) actually cooked
>>>>something up, and used it in production. (I have a vague recollection
>>>>of him demonstrating it to me, back in about October of 2001.) I don't
>>>>know if he's still there, or still on the list, or if the system is
>>>>still in use,
>>>>though.
>>>>
>>>>Bueller? Bueller?
>>>>
>>>>
>>>>        
>>>>
>>>What we're experimenting with is putting assets under version control
>>>(using subversion, of course) as binary otl files. Everyone sources
>>>their own working copy, and commit/update regularly to stay in touch
>>>with the rest of the crew.
>>>
>>>hip files are less and less important. If you want an piece of animation
>>>to be placed under version control you wrap it into an asset and commit
>>>the .otl to the repository.
>>>
>>>So it's not just tools / shaders/ rigs under version control..
>>>sh01_girl_talking would be an outer wrapper asset containing an instance
>>>of girl_face_rig asset with keyframes applied. The .otl containing
>>>sh01_girl_talking contains the keyframes which are thusly version
>>>controlled... yeah!?!
>>>
>>>This is pretty experimental at this stage, but holds a lot of promise.
>>>
>>>Beers,
>>>r.
>>>
>>>_______________________________________________
>>>Sidefx-houdini-list mailing list
>>>Sidefx-houdini-list at sidefx.com
>>>https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Sidefx-houdini-list mailing list
>>Sidefx-houdini-list at sidefx.com
>>https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>
>>    
>>
>
>
>  
>




More information about the Sidefx-houdini-list mailing list