[Sidefx-houdini-list] disappearing HDA parameters

Robert Magee rmagee at sidefx.com
Fri Jun 6 11:46:22 EDT 2008


My interest in the 3Dmax example was not the fact that it covered  
other types of assets (textures, geometry etc) but that it has an  
interface that offers a flattened list that could work well for  
Houdini Digital Assets. I like the fact that it gives you path and  
status info. In the case of HDAs it could also offer a menu of "older  
versions" in case you need to go back. I also liked that it could work  
at a scene level or be expanded to handle studio-wide management.


On 6-Jun-08, at 11:13 AM, paul simpson wrote:

> hi robert,
> thanks for putting this link up.  i think this summarises the  
> magnitude of
> the misunderstanding over the last few years.  it seems most people
> (including sesi?) are getting confused with digital asset management  
> (ie,
> textures, external shaders, geometery) and HDA package management (ie,
> digital asset dependences).  to me, the former is an open ended  
> potential
> quagmire that i would rather sesi leave alone for now.  the latter  
> is imho
> an essential tool that we needed (4 years ago) in order to create and
> package HDA's that in turn use other HDA's within them.  the two are  
> *very*
> different subjects!  (you could - in time treat all external files as
> digital assets - buts that an entirely different topic for now).
> to reiterate - i see the latter as very important as i would like to  
> share
> assets from old jobs, other shops and houdini exchange without  
> having to
> worry about which other assets each one is using.  really, we need  
> all the
> assets to be included in a search path - and each asset can use  
> either the
> latest - or an earlier version all happily and transparently.  i'm  
> thinking
> about continuity between jobs here.  i see this as a universal  
> requirement.
> i would like this logic to be implemented initially in a bare bones  
> fashion
> by sesi - and made open so individual shops can then taylor to their  
> own
> needs.  (please look at debian package management for a great  
> example of
> what i mean).
> the video you point us to refers to the former.  so, to answer your  
> question
> - i would rather any have the hda dependency system implemented  
> rather than
> this tool you refer to.
> we all need to be clear what we're trying to talk about.  part of this
> problem is sesis fault naming HDA's or (OTL's) as "digital assets".   
> it's a
> very generic term within the industry which often refers to texture  
> maps,
> geometry files - as in the 3dsmax example you posted.  nomenclature  
> is very
> important - and needs to be 'normalised' somewhat - or at least
> de-obfuscated.  sesi needs to take the bull by the horns and get more
> production savvy asap.
> this subject has been talked about at cross purposes for over five  
> years
> now!  :-)
> -paul
> 2008/6/6 Robert Magee <rmagee at sidefx.com>:
>> A couple of releases ago, Autodesk put out this movie for their asset
>> tracking in Max8. It starts out as a single window where all the
>> dependencies in a scene are laid out and their current status is
>> outlined (links broken, etc..). From this window links can be re-
>> established and even swapped out for other versions as needed. This
>> system offers a one-stop-shopping for working with local assets. They
>> can then extend that to a network as a "stage 2" of the system:
>> http://download.autodesk.com/media/3dsmax/ 
>> asset_tracking_max8_380k.mov
>> Without going to a full blow asset management system (aka tactic),
>> would something like this meet the needs outlined in this thread? It
>> would be very helpful to figure out exactly how far people would want
>> us to go. When we spoke with customers on this in the past, the
>> requests seemed to lean towards a system that was open and not tied
>> too tightly with Houdini. A Houdini-centric set of tools might be
>> easier in the short term to get people started.
>> Robert
>> On 6-Jun-08, at 10:21 AM, Ken Ouellette wrote:
>>> Paul's problems (I'm assuming here, but based on a hunch of how he  
>>> has
>>> worked in the past) is partly on how he is using HDAs. To that
>>> regard I
>>> don't think he is out of line asking for a bit more support to make
>>> the
>>> packaging and transport/sharing of HDAs easier.
>>> Yes for a small centralized studio it is easier to self manage and
>>> regulate
>>> the changes. For a larger pipeline people will naturally build tools
>>> to
>>> support some sort of revision system, even it is just a slight twist
>>> on the
>>> autoBackup of HDAs and symlinking those to a none versioned  
>>> reference.
>>> Opdepend was an helpful addition for getting some help, but the
>>> process can
>>> still become complex quickly.
>>> There could be some things that Sesi could do to support
>>> encapsulated HDA in
>>> HDAs a bit easier. That has always been a bit of a problem as
>>> finding what
>>> is inside one and understanding its dependencies can be a bit of a
>>> pain.
>>> Then add to the fact that finding certain disk based references
>>> (textures,
>>> geometry, etc) can be a again a bit of a haul to make it work  
>>> easily.
>>> Hopefully some of those basics are easier to handle with python. I
>>> haven't
>>> looked, but even if you made up your own methods to handle all the
>>> cases it
>>> would take you a while. It all depends on how absolute you want to
>>> be in
>>> your version of the asset, not just the HDA. The HDA itself is a
>>> container
>>> with parameters, you can inject some of its components (geometry,
>>> and low
>>> rez textures) but other items like high rez textures, and rib/ifd
>>> files
>>> either don't work in the context (I know Renderman doesn't like it,
>>> not sure
>>> about Mantra). So when it comes down to it there are a lot of
>>> support files
>>> you need to consider when you are planning out your pipe.
>>> It gets more complex if you start to encapsulate HDAs inside HDAs
>>> and then
>>> it can become very important for the order in the loading/
>>> instantiation and
>>> then add the dependency issues across these nested HDAs. The
>>> flexibility in
>>> Houdini makes it really difficult to contain. Having had a large
>>> role in
>>> building two asset management systems for Houdini, it is very
>>> difficult to
>>> keep things agnostic and actually requires more structure then you
>>> would
>>> expect. There are many ways to create HDAs  and it becomes a job
>>> just to
>>> support the different methods. That is part of a natural process of
>>> having
>>> and maintaining a pipeline vision and should be expect with every
>>> system
>>> though. I do feel it is more of a challenge in Houdini than in other
>>> products ( <cough>Maya<cough>)
>>> When I saw what Sesi was doing with python and H9 I really stressed
>>> to them
>>> that with a hand full of people any studio could quickly flesh out a
>>> very
>>> sospicated pipeline if they had some experience in doing it in
>>> previous
>>> versions. Having Sesi provide blue print type examples on how to set
>>> up a
>>> system would be great but also starts a slippery slope for them.
>>> Where does
>>> providing added value stop with support? That is a difficult problem
>>> for any
>>> software vendor and one most avoid. I can't blame them
>>> The embedded browser is very helpful to develop an app to handle the
>>> management of the assets, but there are challenges that inherit to
>>> using
>>> that environment. Thankfully Sidefx has made huge efforts to remove
>>> a lot of
>>> these but there are still cycles to be spent finding ways to around
>>> them. In
>>> the end it is the same problem of Sidefx entering a slippery slope
>>> of where
>>> to draw the line for support.
>>> For "a irritated Georg"
>>> Encapsulation for a entire can be easy to implement but has serious
>>> draw
>>> backs for updates, both HDA wise and parameters. On the Wild we had
>>> a fairly
>>> strict rule that we supported only HDAs, which added its own
>>> complexity to
>>> making things (think of how hard it is/was to make a dynamic
>>> parenting HDA).
>>> We knew what  HDA's whet into a hipfile and what verison they were,
>>> we also
>>> saved out all the animation for the files. In some cases we wrote  
>>> out
>>> geometry and had special HDAs to handle those cases.
>>> Saving and versioning entire hipfiles and keeping track of the
>>> versions of
>>> any HDAs inside....  for a production pipeline is a bit easier and
>>> can offer
>>> some benefits, but still has some drawbacks. That method that was
>>> used as
>>> well post "the Wild" in a number of shows.  There are always
>>> challenges
>>> about updating versions and handling animation.cmd files.....
>>> keeping track
>>> of changes between saved hipfiles when it comes to non-HDA elements
>>> anyone
>>> can create in Houdini. Connections parenting all that jazz
>>> The real power is to find a method to manage all the information and
>>> push
>>> changes out on the fly. Then you complete the circle of the pipeline
>>> and you
>>> have the ability to make large sweeping changes effecting renders
>>> going to
>>> the farm.
>>> I should stop now.. that is long enough to read :)
>>> -k
>>> On Fri, Jun 6, 2008 at 7:48 AM, Pablo Giménez Pizarro <
>> pablogipi at gmail.com
>>> wrote:
>>>> El 06/06/2008, a las 13:33, Peter Robbinson escribió:
>>>>> Hi,
>>>>> It had a lot to do with the asset manager.
>>>>> There were specialists, Michael being an important one, who were  
>>>>> the
>>>>> responsible for developing and maintaining the digital assets.
>>>>> The artists on the production floor accessed the appropriate  
>>>>> assets
>>>>> for
>>>>> a given scene through the embedded browser. Core used the embedded
>>>>> browser to present an interface to the asset manager. Artists only
>>>>> had
>>>>> access to the approved assets for an assigned scene. There were  
>>>>> ways
>>>>> to
>>>>> access earlier versions of assets, but only when problems were
>>>>> encountered. The assest manager allowed artists to report problems
>>>>> (bug
>>>>> reports) and these were automatically reported to the appropriate
>>>>> department.
>>>>> Michael play a big part in getting that system to work, it was  
>>>>> quite
>>>>> remarkable. That's not to say it worked well all the time, there
>>>>> were
>>>>> plenty of work-arounds necessary and it took time to get working
>>>>> right,
>>>>> but it was certainly the best pipeline I had ever encountered.
>>>>> Keep in
>>>>> mind Core used version 6 of houdini on that production and digital
>>>>> assets were brand new.
>>>> Thanks for the explanation Peter.
>>>> Now I think that you are agree with me that to take the most from  
>>>> HDA
>>>> you need some management tool.
>>>> I am not talking to have this complex system developed at CORE but
>>>> something simple and easy for the small studios that use tools that
>>>> can be used by big houses to develop their own management systems
>>>> (like the otlversion command for example)
>>>> In my opinion SESI did really well with the character picker and  
>>>> pose
>>>> library tools, something like this, in the browser will be great.  
>>>> The
>>>> pose library for example is not the most advanced tool, but it  
>>>> works
>>>> out of the box and for a small studio do the job and if you need to
>>>> extent it you can.
>>>>> PeterR
>>>>> Georg Dümlein wrote:
>>>>>> Michael Goldfarb <goldfarb at coredp.com> schrieb:
>>>>>>> The Wild was made almost entirely (like 95%+) without hip  
>>>>>>> files...
>>>>>> Sorry for the noobish question , but:
>>>>>> How does this work?
>>>>>> Are you using HDA that contain the complete scene?
>>>>>> a irritated Georg
>>>>>> _______________________________________________
>>>>>> Sidefx-houdini-list mailing list
>>>>>> Sidefx-houdini-list at sidefx.com
>>>>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>>> --
>>>>> "gravity is not a force, it is a boundary layer"
>>>>> "everything is coincident"
>>>>> "Love: the state of suspended anticipation"
>>>>> "To get any appreciable distance from the Earth in
>>>>> a sensible amount of time, you must lie."
>>>>> "Easy, is not how you make a living."
>>>>> _______________________________________________
>>>>> Sidefx-houdini-list mailing list
>>>>> Sidefx-houdini-list at sidefx.com
>>>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>> ---------
>>>> Un saludo
>>>> Best Regards
>>>> Pablo Giménez
>>>> pablogipi at gmail.com
>>>> _______________________________________________
>>>> 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
>> ----
>> Robert Magee
>> Product Marketing Manager
>> Side Effects Software Inc.
>> www.sidefx.com
>> 416 504-9876 x327
>> _______________________________________________
>> 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

Robert Magee
Product Marketing Manager
Side Effects Software Inc.

416 504-9876 x327

More information about the Sidefx-houdini-list mailing list