[Sidefx-houdini-list] disappearing HDA parameters

Ken Ouellette ken.ouellette at gmail.com
Fri Jun 6 11:57:17 EDT 2008


Hi Mike!
:)
thx

On Fri, Jun 6, 2008 at 11:55 AM, Michael Goldfarb <goldfarb at coredp.com>
wrote:

> yeah...what he said.
>
> Hi Ken!
>
> 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
> >
> >
>
> --
> .......................................................................
> 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
> _______________________________________________
> 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