[Sidefx-houdini-list] disappearing HDA parameters

rachael rachael at methodstudios.com
Fri Jun 6 13:26:01 EDT 2008

I would agree that versioning could really use some help. It'd be great 
to have a version tab in the Type Properties Manager. It'd be really 
easy to understand and straight forward that way.

Pablo Giménez Pizarro wrote:
> For all the topics we have been covering in this thread can be  
> splitted in 3 areas:
> - Versioning
> - Dependencies
> - Asset managing and tracking
> Every topic depend from the previous, is impossible to have  
> dependencies tacking without a correct versioning and again is  
> impossible to have a correct asset management without versioning and  
> dependencies.
> So following paul the first thing is to have something easy to make  
> the versioning in the HDA, for example why there are only an  
> otlversion, not and hda version? And why is so hidden in an hscript  
> command.
> For me makes really sense to have in the Type Properties window a  
> section to manage the version of the current operator I am editing, so  
> if I make a change a can change the version easily, and check the  
> version in a friendly way.
> Will be great that when checkout an HDA, when you click Accept in the  
> type properties for example, the tool looks for all the dependencies  
> on other HDA and the corresponding version, so you can save the info  
> of all your dependencies with the tool and then if any problem arrives  
> loading or using the tool you can compare your current HDA with your  
> dependencies. Also a tab like "Dependencies" in the properties dialog  
> will be really useful.
> All of these will be accesible via python if you want to do things  
> offline.
> And lastly and mainly useful for small houses will be something  
> similar to the tool proposed by Robert about the tracking asset in 3D  
> Studio. At this point big houses can use all the versioning and  
> dependencies tools provided by Houdini to develop their own management  
> system.
> For small studios a tool that have a data base that keeps track of  
> files and assets in your scene is really useful.
> Again we can use the example proposed by paul about deb packaging  
> system.
> The deb packages database in Debian doesn't contain the binary data of  
> the packages themselves, only the metadata and the links to the  
> location of the data. It is possible to develop an interface on top of  
> many open source tools, like sqlite, or berckeley database, to create  
> a data base that keeps track of all the HDA defined by all the otls  
> included in the search paths, track the versions, track external files  
> these are using, hip files, etc ...
> For me the first two are really needed, this last will be great for  
> small studios and definitelly add value to Houdini, but is not a must.
> El 06/06/2008, a las 18:06, paul simpson escribió:
>> hey robert,
>> for sure - that would be useful functionality.  my points about
>> differentiating between package and asset management certainly
>> weren't solely directed at you.  i believe that it's very important  
>> that we
>> all get on "the same page".  (god - i hate management speak!) ;-)
>> -p
>> 2008/6/6 Robert Magee <rmagee at sidefx.com>:
>>> Paul,
>>> 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.
>>> Robert
>>> 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
>>>>>>>> --
>>>>>>>> "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."
>>>>>>>> Robert Magee
>>>>>>>> Product Marketing Manager
>>>>>>>> Side Effects Software Inc.
>>>>>>>> www.sidefx.com
>>>>>>>> 416 504-9876 x327

More information about the Sidefx-houdini-list mailing list