[Sidefx-houdini-list] disappearing HDA parameters
goldfarb at coredp.com
Fri Jun 6 11:55:29 EDT 2008
yeah...what he said.
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 :)
> On Fri, Jun 6, 2008 at 7:48 AM, Pablo Giménez Pizarro <pablogipi at gmail.com>
>>El 06/06/2008, a las 13:33, Peter Robbinson escribió:
>>>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
>>>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
>>>access earlier versions of assets, but only when problems were
>>>encountered. The assest manager allowed artists to report problems
>>>reports) and these were automatically reported to the appropriate
>>>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
>>>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.
>>>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
>>>"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
>>pablogipi at gmail.com
>>Sidefx-houdini-list mailing list
>>Sidefx-houdini-list at sidefx.com
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
Michael Goldfarb email: goldfarb at corefa.com
c.o.r.e. digital pictures http://www.coredp.com
"Unless you're an astronaut, secret agent, vampire hunter,
or all three, you're probably a sellout; screw you."
- Maddox 2003
More information about the Sidefx-houdini-list