[Sidefx-houdini-list] disappearing HDA parameters

Ken Ouellette ken.ouellette at gmail.com
Fri Jun 6 10:21:43 EDT 2008

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ó:
> > 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

More information about the Sidefx-houdini-list mailing list