Houdini Weaknesses

[Francois Lord]

So...
What are houdini weaknesses? What is missing in Houdini compared to
Softimage? Would you run a company only using Houdini as 3D app? Why not?

[Artur Woźniak]

Learning Curve

Wysłane z iPhone'a

[Sebastien Sterling]

well... there's no organic modeling ?

[Ed Manning]

For NYC anyway, the main weakness is the small base of trained artists. Then there's the fact that most of them are fairly senior TD-types who charge justifiably high rates, and are either overqualified for most artist-level assignments, or just not character animators since most of the Houdini artists I know are focused on FX and sim work (assuming that Houdini's character animation tools are in fact up to the job). Then there's the relatively high cost of Houdini itself, the lack of Arnold support, the steep learning curve that makes it hard to train anyone but a dedicated staff artist in Houdini...

Don't misunderstand -- it's an awesomely powerful tool in the right hands; I wish I had taken the time to learn it years ago.  But just as I wouldn't want to run a woodshop that did all of its work using, say, CNC mills and lathes instead of hand tools, I wouldn't want to run a small commercial CG shop with just Houdini.  I mean, you *could* do it, and the work could be done at awesome quality, but it would be pretty strange workflow at times and very expensive I think.

[Sergio Mucino]

My personal experience it's that it's not an artist-friendly tool. It's incredibly powerful, but it requires quite a bit of technical knowledge and the learning curve is steep. I know many artists (modelers, animators, environment artists) that the moment you bring up a graph, they start bleeding from the nose. It's hard to avoid these workflows in Houdini.
I'm not sure I would solely re a production in Houdini purely for this aspect. However, complimenting it with a more "traditional" DCC, it'd make up for a killer combo.

Sergio Muciño.
Sent from my iPad.

[Oscar Juarez]

About the Arnold Support, there is indeed arnold support.

https://vimeo.com/81443048

[Jon Swindells]

houdini is pretty much where it was 6yrs ago, utterly fantastic procedural workflow. abysmal for anything else,

 

normal modelling tasks are painful. forget uv/topo work. the tools just aren't there and the selection model gets in the way.

 

rigging is light years ahead of anything i've ever seen but it's mostly moot because the anim workflow is dire compared to xsi (or any other app for that matter)

 

sim/fx - no real need to comment on this other than to utter 'sweet mother of god!! look at the waves!' :)

 

mantra is the poodles plums

 

the glsl implementation has the potential to make vp 2.0 look like s/w TnL - i got matcap, a rudimentary grease pencil and currently having a go at getting a pixar style rig selection/manip workflow going. viewport tech is fantastic

 

 

 

 

 

 

i'm having a rather bizarre time with houdini. 

 

--

Jon Swindells

jon_sw...@fastmail.fm

 

[Andy Nicholas]

From my experience, it's still relatively slow. A lot of stuff is still single
threaded although they've done a lot of work to improve that recently. Be ready
to eat up a lot of disk space too, as you'll be caching stuff out all the time
to make up for the lack of speed.


Despite what many say about Houdini being great for particles, compared to ICE,
the particles workflow is bloody awful. The nodes are super basic which means
you have to roll your own out of VOPs, which are then super slow. ICE and Arnold
are a dream for instancing, but Houdini drives me insane with slow and flaky
workflows (although I probably need to update my knowledge since some of the new
features have come out - e.g. packed primitives).


Generally in production, expect not to see any significant results out of
Houdini artists for the first 70-80% of the job. That can be a real pain for
working with needy clients. Once you get past that point though, they'll be able
to turn new versions out very quickly. Unfortunately, if it doesn't look good at
that point you've got a crap load of work to redo, and it can really bite you in
the ass if you don't have a good backup plan.


When it comes to commercials, not a lot beats ICE and it's rigid body
implementation for speed and ease of use, and I really miss not having that in
Houdini. Doing simple stuff in Houdini's DOPs can require an hour of research
trying to find out what data you need to modify, and how to actually implement
it.

I could go on a lot longer, but all I'll say is that you have to be super
careful when you decide to throw a job at Houdini. Make sure you have R&D time
built in if you haven't done a particular effect before.

A

[Francois Lord]

And how would it fare as a lighting/shading/rendering hub?
I'm very hesitant to move to Maya just for it's lack of a true a pass
system. But then, there's only Houdini and Katana. We could add to the
list Modo and Clarisse (which I'm surprised nobody talked about here
yet) but we need Arnold.

[Meng-Yang Lu]

I really like the idea of Houdini as the hub for lighting.  Considering most FX are now done in Houdini anyway, it sort of houses two rather complex aspects of CG really nicely.  

ROPs isn't really a pass system but think of it more like separable render globals for all outputs.  Probably one of the least touted feature of Houdini but definitely one of the most luxurious feature set.  You can pick and choose to your hearts desire what can be done via AOVs, what grouping of ROPs you want to use, and what should be overidden via Takes (though usually shyed away from).  

We've had Maya guys migrate over feeling really bummed having to go back to Maya's pass system.  

-Lu

[Sebastien Sterling]

can't mtoa bypass maya's shitty pass system ?

[Andy Nicholas]

Sure. There's certainly a lot of potential there. It's just that the openness
means that the workflow is very open to interpretation. Houdini's a bit like
coding, everyone has their own style so you can get in a mess. It's very easy to
add in quick little "fixes" which other people might look on as hacks instead.

A

[Jordi Bares]

Houdini, like Maya, Softimage, Modo, Cinema4D, Max, etc… is not perfect and has some flaws.

In my opinion after doing the transition I still miss a few things but these are the key ones

- Procedural modelling is useful but the whole non-procedural workflow is in this age very bad, for this reason all Houdini artists either rely on a modeller using whatever that guy likes or simply use a Zbrush + retopology approach. So no biggie but for small things is a pain in the ass.

- Viewport is not great, and specially the whole application is not really viewport centric so you can see the tools operate mostly on the network view with some quirky approach to the viewport (for mirroring skeletons is an operation done on the viewport, a non-procedural one) So you will get used like me but won't like it.

- Shading is very granular and the examples and setups provided are not very good so once you get it is good but not great yet. The actual implementation of Arnold for Houdini is soooo much user friendly (looks a quite a lot like the render tree to be honest)

- Animation tools are not there yet, not too bad but you will miss the mixer and specially the animation layers. I don't particularly like the f-curve interpolation but that is not that big of a deal really.

All in all these are my issues with Houdini, the good news is that they are working on these so we may find a first batch of improvements very very soon which will make it easier to access.

Regarding some comments about Houdini, it may be a bit slower as the multithreading is not being finished, there were massive improvements on the last versions (some nodes running 2500x faster) so together with new OpenCL support and multithreading on the pipe this problem should be gone (just look at Pyro with a proper K5000 graphic card and you will see what I mean)

Regarding talent the truth is that mostly are FXTD and it shows in how they work and the training has been geared towards that as sidefx did want to position themselves there and truly they are untouchable on that area but yes, you needs some good people supporting a bigger team.

Regarding artist friendliness, it is simply that it is quite different in approach but like Zbrush, once you pass that point which is not that hard (look at my transition guides here http://www.sidefx.com/index.php?option=com_content&task=view&id=2711&Itemid=132 you will see it is pretty similar to XSI.

Regarding the learning curve, if you want to get directly into dynamics, particles and vex then be prepared to dive into some more complex stuff, I would recommend to start with the basis and you will feel comfortable quickly.

It is very true as Andy pointed that Houdini is very granular (for example, only recently you see flocking as a tool, till now the approach was for you to build it your way) but the attitude is changing fast and you can see Side Effects responding quickly.

Regarding Softimage I would put it this way, I still love it and even with the lack of proper muscle deformers, limit with number of objects, awful viewport and pretty bad sdk documentation I still think is the best 3D tool but the problem is that the very clever people at Autodesk has killed it so no very good.


As I said, I could set a list of things I don't like about every single particular package, to me the fact that houdini scales massively to super-complex stuff you can't even open in Maya or Softimage plus the fact they have the best support makes me thing is the best bet for my career. Plus you get paid more and do the really nice stuff. ;-)

So again, would I configure a studio with Houdini as the only package? well, that is my daily basis and works very very well although of course I have around me a few true experts.

Would I set it up with Softimage instead if was still available? oh man, yes… would get both in fact!!!

hope that helps.


Jordi Bares
jordi...@gmail.com

[Jordi Bares]

It is the same with any package the only thing is that Houdini artists tend to be more of a peculiar type… you just have to make sure they stick to the conventions like all Softimage users do (for example on how we setup passes)

Jordi Bares
jordi...@gmail.com

[Andy Nicholas]

Sure, conventions are always necessary, but more so with Houdini. Some people
use Takes as passes, others use ROPs with object masks into subnets as passes.
Or you could use a mix of the two approaches.


At least in Soft, passes are passes!


A

[Jordi Bares]

I do miss XSI passes a bit… The thing as you know is that there is no the concept of passes, you can mimic it although not 100% so people just find their approach and become very proud of it not knowing XSI has the very finest system since day 1.

I never use takes for passes but for overrides and use ROPs together with bundles instead of explicit references of "object merge" style approaches.

The thing I am not sure i want to give up now is the approach of ROP networks dependencies so I can trigger very complex setups and simply go home.

;-)

Jordi Bares
jordi...@gmail.com

[Andy Nicholas]

BTW, it's worth saying that despite all the faults I've mentioned, I still love
using Houdini. Especially now that it's my main route of escape from the
wonderful world of Maya ;) And for those who are looking for a tool to support
complex effects, I'd totally recommend getting into it.

If you haven't checked out Jordi's PDFs on SideFX's website yet BTW, that should
be your first port of call as they're a great transitionary guide.


A

On 21 May 2014 at 22:16 Jordi Bares <jordi...@gmail.com> wrote:

[Andy Nicholas]

Hehe! There you go, another variation ;) I've not tried that one, but that
sounds like a better way of going about it than my previous attempts with
instancing into subnets.

[Francois Lord]

Yeah, the only reason I have not yet dived into Houdini yet is because
of lack of time. As soon as I can, I will be reading those pdfs.
But I do have to choose my next move not too late, for me and for the
company I work for. Over here, we are 18 cg artists working in
Softimage. No one is excited to learn Maya, but Im not sure we can skip
it entirely. Houdini seems a good first step for look dev since Arnold
is coming. We can keep rigging and Animation in Softimage for a while.
Modeling can be done in any package, it doesn't matter.

F

[Matt Lind]

Seems like Houdini is heavy on nodes and expressions to create your work.

How much custom plugin development do you have to do with Houdini compared to Softimage, Maya, etc...? Let's define a plugin as something you'd write as a script or C++ lib that gets included in the software as a reusable tool, perhaps providing it's own GUI front end (if applicable) and is responsible enough to do proper error checking (as opposed to a couple line hack script like many artists do).

Is there much of an SDK for writing GUI's as front ends for tools?


Matt

[Meng-Yang Lu]

Yes.  It's nodes and expression heavy.  And for that same reason it drastically reduces plugin development cause you're essentially programming every time you're in the package.  And just like you'd copy and paste snippet of code, you'd do the same but with nodes of a tree.  

Whenever I feel like I need to do dev work in Maya which is often, I just go to Houdini now.  

The UI creation is also pretty nifty.  You basically have access to all the params, sliders, and widgets you'd normally see in Houdini's default tools.  Just a matter of dragging, dropping, and organizing to your heart's content.  You can promote params from a lower level to a higher level at anytime, exposing only what you want the artist to see.  

You can do error checking either through the nodes or through vops/vex.  

It's got one foot in as a 3D application and 2 feet in as a plug-in development platform.  Yes, 3 legged analogies are weird, just like Houdini.  But I like it now.

-Lu

[Matt Lind]

That makes sense for an FX workflow as every project is essentially unique, but in a production where you churn out a lot of carbon copies or variations of the same content, how well does Houdini’s framework/workflows cater to that?  For example, are there mechanisms or abilities to enforce certain ways of working?  That’s probably our biggest concern as our content has to be functional, not just look good.  To be functional requires certain elements be consistently defined on the assets and the asset structured in particular ways.

 

One weakness I see so far is the lack of API for hardware shader development. GLSL is there, but it’s slow compared to straight OpenGL.  I haven’t looked very deeply, but at a quick glance I don’t see any Direct X support.

 

One thing that would be really useful for the transition guides is more focus on modeling and texturing.   Houdini seems to have  the basic building blocks, but the rest has to be developed/configured by the user.

 

Matt

[Meng-Yang Lu]

This is actually where Houdini shines.  Taking something that exists and manipulating the DATA to create something new.  

Say you've got characters that have like belts of ammo as an accessory.  You can create a dependency saying something like... if you choose type bullet, it also drives the number of bullets on the belt.  So if you choose type grenade which are larger in size, that type can drive the lesser number of grenades on the belt.  Between nodes like copy/stamp and switches, you can build these into your system.  You could, if all the assets are there, build a character creation system seen in a lot of games if you wish.  Even up to clever things like stating which type of weapon the character is holding.  Like if a weapon is two-handed by type, you could never have a single-offhand accessory, thus never having things that could conflict if both existed.       

The best way to think of Houdini is not just an FX tool.  It's an operating system that manages 3D data and does it extremely well.  This is why it takes a long time to build the setup, but the payoff is that over time, you gain a huge advantage of creating various version of one thing as long as you've built it into your setup.  

Modeling and texturing really should be done somewhere else.  But once those assets are create and you want to manipulate it, Houdini become a really powerful ally in this case.  

-Lu

  

[Sajjad Amjad]

How much custom plugin development do you have to do with Houdini compared to Softimage, Maya, etc...?  Let's define a plugin as something you'd write as a script or C++ lib that gets included in the software as a reusable tool, perhaps providing it's own GUI front end (if applicable) and is responsible enough to do proper error checking (as opposed to a couple line hack script like many artists do).

if you're talking about the lines of code to get the same stuff done in Softimage or Maya, I would say it really depends on how you approach the problem. As with all things Houdini, there are multiple ways of making plug-ins/nodes with custom GUIs. You can create the whole layout dynamically (similar to using parameters and PPGLayout in Softimage), or you can manually create the layout and connect it through scripts. I tend to do everything programmatically to keep everything in one place. I've written plenty of plug-ins which provide exactly the same functionality in various DCCs including Houdini. The code for Houdini was similar in length to the others. 

If you're talking about general custom plug-in development, I guess the answer would be the same for any DCC that needs to be integrated in to the production pipeline. I'm assuming, for a game studio, you have very strict rules to govern where things go in the file system. Based on your previous posts on the topic (of moving away from Softimage), I think it's safe to assume you'll need to do a fair bit of custom development.

 

Is there much of an SDK for writing GUI's as front ends for tool

In short, yes. My personal experience with the Houdini SDK has been fantastic. I don't recall hitting a brick wall. Going off on a slight tangent, the only thing which irritated me was lack of Python support for viewport capture. However, that can be easily done through Hscript. The good news is that it will come for Python (it's in the roadmap). For GUIs, Houdini allows using native widgets or going down the PyQt path. Thankfully, there's none of that event loop issues that Softimage has when using PyQt. My personal preference is to use native widgets as they allow for a consistent UI experience. As mentioned earlier, you can create GUIs manually (drag and drop) and link them through scripting, or you can create them programmatically. Both approaches have their merits. The Houdini Python Shell is best of breed. Imagine getting a reference to an ICE node in Softimage by dragging said ICE node in to the Script Editor, this works in Houdini. Also, hurray for auto-complete virtually wherever you can write scripts.

From a pipeline integration point of view, I think the biggest mistake people make during transition is to try and find one-to-one correlation between workflows and concepts. The best you can hope for is similarity of some concepts. There are no workgroups or custom parameter sets, however, there are equivalents which work perfectly well. Some find it strange that Houdini has no default project structure, I rather like it (now). The lack of a project structure is a testament to the fact that Houdini can be integrated in to whatever structure you're using currently. 

Sajjad

[Nick Angus]

A very wise person advised me quite a while ago when I was at a crossroads and Soft was still very much alive.  I sent an email to Andy Nicholas asking his opinion as I knew The Mill were using Soft and Houdini.  Andy described Houdini to me as not so much a 3d application as an operating system for a 3d environment.  After spending some serious time with Houdini recently I couldn't think of a more apt description.

As far as I am concerned the animation/rigging war is over and Maya won, not on merit of course…. But that doesn't make much difference when you are looking for a freelance rigger or animator to hit the ground running.

So we find ourselves using Soft as an asset assembly tool for lighting/shading/fur/rendering, with effects and lots more  from ICE. It has worked brilliantly thanks to Alembic and a few tools we have built on the fly.  But more and more I am finding the need for things that Soft cannot do such as fluids, Smoke and destruction or a nasty combination of all of that!

When I say Alembic I mean pointcache only, the asset is shaded/fur-groomed/look developed entirely in Soft.  We import the assets into a shot and then import animation onto them that is published from Maya.  It is a pretty sweet way to work, and lets us turn around commercial jobs in amazing time.  It allows us to (once basic rigging has started) parallelise your production and no one sits around waiting for handover.

I agree particles are at the moment probably better in ICE, but more from a motion graphics perspective than anything else.  So it has effects covered, shading is pretty good too, especially with the addition of the new workflow in HtoA.  The way it handles Alembic out of the box is brilliant also.

Mantra would probably be my next choice behind Arnold as a renderer also.  The tests for me will be instancing compared to the ICE workflow, particularly with Milan Vaseks awesome scatter tools that I depend on so much!   And fur, fur looks pretty hard and slow to me right now, when even Softs old fur tools are still pretty amazing.

The other biggie for me is Houdini Digital Assets, a really nice way to publish out tools or assets with lots of control. It really is the only App other than Soft that I would trust with referencing in complex assets.

I have lots to learn, but I think I am going to put Houdini up as the backbone of the company over the next 18 months or so.  Soft will still be there and many jobs will probably still go through that pipe depending what they are.  But I am sure I will end up crossing over completely at some point down the track.

Cheers, Nick

[Jordi Bares]

On 22 May 2014, at 01:54, Nick Angus <Ni...@altvfx.com> wrote:

As far as I am concerned the animation/rigging war is over and Maya won, not on merit of course…. But that doesn't make much difference when you are looking for a freelance rigger or animator to hit the ground running.

Animation toolset is the simplest of areas to improve (let's face it, animation requires a few simple tools) and the rigging toolset in Houdini is far superior to the one in both XSI or Maya so my feeling is that if you want to use it for character animation it is not a problem as we do day in day out at Realise.

jb

[Jordi Bares]

That variation is documented on my guides and believe me, you will love it.

Jordi Bares
jordi...@gmail.com

[Jordi Bares]

Have a look at the transition guides I am writing, download them on your iPad and read them (it is fast to read, promise) so you can take an informed decision, be either Houdini, Maya, Modo, whatever you like.

My feeling is that a transition period with FX and rendering in Houdini to later decide to either buy more time or commit to package X is the safest route right now.

Plus render nodes are free and believe me, that adds up really easily so with one FX license and normal ones you can go really really far.

cheers

Jordi Bares
jordi...@gmail.com

[Andy Goehler]

On May 21, 2014, at 23:15, Jordi Bares <jordi...@gmail.com> wrote:

- Shading is very granular and the examples and setups provided are not very good so once you get it is good but not great yet. The actual implementation of Arnold for Houdini is soooo much user friendly (looks a quite a lot like the render tree to be honest)

Hi Jordi,

I’m not quite sure I understand regarding Arnold in Houdini. Wether using Mantra or Arnold it ends up with a similar VEX graph doesn’t it? If I drop down a Mantra shader using a ‘Surface Shader Builder’ I get an empty ‘Rendertree’ – adding a ‘surfacemodel’ I’m right at home, no difference to Arnold. Maybe I’ve missed something, what are you referring to user friendliness in particular?

What I do love, and stated elsewhere on the list, is the flexibility that Mantra brings with it without having to go full C++ in an IDE.

cheers

Andy

[Francois Lord]

That has been my intuition so far as well.

[Jordi Bares]

below

On 22 May 2014, at 11:35, Andy Goehler <lists.and...@gmail.com> wrote:

On May 21, 2014, at 23:15, Jordi Bares <jordi...@gmail.com> wrote:

- Shading is very granular and the examples and setups provided are not very good so once you get it is good but not great yet. The actual implementation of Arnold for Houdini is soooo much user friendly (looks a quite a lot like the render tree to be honest)

Hi Jordi,

I’m not quite sure I understand regarding Arnold in Houdini. Wether using Mantra or Arnold it ends up with a similar VEX graph doesn’t it?

Yes it does but Arnold has reconstructed a ton of nodes you will use on a constant basis that are nicely packaged like in mental ray phenomena.

If I drop down a Mantra shader using a ‘Surface Shader Builder’ I get an empty ‘Rendertree’ – adding a ‘surfacemodel’ I’m right at home, no difference to Arnold. Maybe I’ve missed something, what are you referring to user friendliness in particular?

It is difficult to explain to be honest but I will encourage to try to add a noise function on one of mantra surface node inputs… instead of having a plug and job done you will have to dive in and wire it by hand which is not as fluid.

The good part is that you can dive in, the bad part is that your though process is disrupted.

The best solution is to modify mantra surface yourself to have a version for you that allows you to plug things… negate things, etc…

What I do love, and stated elsewhere on the list, is the flexibility that Mantra brings with it without having to go full C++ in an IDE.

100%… it is worth the extra work and let's face it, Mantra is free for any number of nodes… no wonder some major players in London are moving to Houdini in a big way.

jb

cheers

Andy

[Andy Goehler]

Thank you for expanding on the subject Jordi,

having a second look, it is apparent that you can only access Arnold compatible nodes inside Arnold Materials. Also the image node for example comes with UV options that indeed is so much more user friendly.

cheers

Andy

[Jordi Bares]

Indeed, and that is what I am talking with Side Effects, "guys, this is very important thing, look to HtoA for inspiration"

Jordi Bares
jordi...@gmail.com

[Christian Gotzinger]

From everything I've seen so far, Houdini is built in a very logical fashion, and I'm not under the impression that it's so much harder to learn than other applications.

My experience with it has been very positive so far. I haven't had much time to put aside for learning Houdini yet, I'd say I've spent about 8 hours watching tutorials and about 25 hours getting to know Houdini. When working with the application myself, I exclusively looked at procedural modeling because that's what I'll need it to do first and foremost.

The first steps were difficult, but once I grasped some general concepts I got up to speed rather quickly. My main issue right now is not knowing all the nodes and attributes there are. I discover new things every day, and I enjoy the experience a lot. Things I've been wanting out of ICE for a long time (support for generating curves, basic modeling operators like bevel, support for strings and text, a symbiosis between ICE tree, render tree and FX tree) are all built into Houdini. It feels like a paradise, the possibilites seem endless.

Today I put together my first reasonably complex digital asset, and even though I don't know Houdini well at all yet and ICE extremely well, I'd say that it would have taken me longer to build the asset in ICE! On top of that, in ICE I would have had to jump through several hoops due to lack of curve support, the resulting tree would be a mess due to all the low level nodes it would have required, and the resulting compound would not be as easy to put together and turn into an artist-friendly UI.

I know that Houdini is not the greatest viewport modeler and probably has some other shortcomings, but with regards to procedural modeling the transition from ICE has been easy and pleasurable so far.

Christian

On Wed, May 21, 2014 at 8:58 PM, Artur Woźniak <artur...@gmail.com> wrote:

Learning Curve

Wysłane z iPhone'a

[Andy Nicholas]

Lots of good comments on this thread.


One last thing that just occurred to me... It's very easy to have lots of fun
building cool tools, playing with new features, investigating new ways of doing
things in a virtual playground of awesome 3D technology. Yep... Very very easy
indeed.

Why's that a problem? Because sometimes you forget you're actually there to do a
shot with a very real deadline.

Oops.

Seriously. I've seen it happen so many times where people (myself included) fall
down the rabbit hole, playing with things, trying to figure out why their
particular workflow doesn't work. Often there's a really simple solution, but
it's very easy to get fixated on the technical issue at hand.

It's always worth asking yourself every 30 minutes; is this the best use of my
time?

:)

Dnia 21 maj 2014 o godz. 20:42 Francois Lord <flord...@gmail.com

<mailto:flord...@gmail.com> > napisał(a):

[Francois Lord]

I have the very same problem with ICE anyway.

[Matt Lind]

Replicating bullets and stuff like that is not the kind of carbon copying we need as cloning would cause problems.  Every asset needs to be unique and trackable, so having a master mesh and running a bunch of ops to clone/duplicate/instance is not really the target we’re aiming for.  Although that functionality is useful, it’d probably be more directed at building parts of environments than characters or props.

 

What we need is the ability to constrain users from going outside the lines we’ve drawn.  Imagine a yard with tall electrified fences.  Users are allowed to roam anywhere in the yard, but are not allowed outside the fence.  As we iterate on our pipeline, we push the fences further and further out to get users more room to roam.  But the constant is we need to persist metadata on the assets and prevent that metadata from being inadvertently modified as well as ensure the metadata is applied in such a way it can be reliably found and relied upon to drive tools and behaviors within the pipeline.

 

For example.

 

Our characters are built like Mr. Potato head dolls.  They are not a single seamless mesh.  There is a base body mesh, but holes left for other parts to plug in such as ears, faces, hair, clothing, etc…   The locations for the body parts are defined by clusters, custom properties, and other metadata.  Once the character is defined it’s placed in a referenced model to prevent users from tampering with the metadata to ensure tools are reliable and can find, track, and assemble the parts with other assets to create what the artist needs to pull into a scene to do his/her work.  Same rules and generalities apply to other areas of the pipeline.  Render passes are used to allow artists to build the environment geometry once, and redress it many times with texture and shader swaps.  Since some of the metadata describes components which customers can purchase, the assigned IDs for the components needs to be maintained and be tamper proof.

 

Does Houdini offer mechanisms to control assets in this fashion to ensure data integrity year over year in a fluid pipeline?

[Andy Nicholas]

God yes. With bells on.

If you think that Softimage is good on that front, you'll fall hopelessly in
love with Houdini.

A

[Meng-Yang Lu]

I'm trying to correlate the languages of both packages.  

Maybe Andy Nicholas can double-check my work but Houdini Attributes behave like custom data throughout all component and object levels of any asset.    Groups act like clusters which you can use to apply whatever attribute (metadata) you want and impart various behaviors based on them.  

As far as things being tamper proof I'm not sure.  The Mr. Potatohead reference is absolutely doable and probably easier imo than Softimage.  There's a whole ecosystem built around managing arbitrary data in Houdini.  

-Lu 

[Matt Lind]

I think Softimage is OK on that front. Good in some areas, lacking in others. Almost anything we've had to do Softimage got us 80% of the way there fairly quickly, but the problem has always been getting that last 20% which is often the most critical part. I've probably spent more time than I've cared for to work around the lacking points or limitations. The lack of open file format and ability to deal with nested models reliably has been a hindrance. Softimage relies too much on top-down cascading propagation and needs more support for lateral relationships such as groups and sets to establish dependencies.

Basically I've had to come up with a logical design for a pipeline that can accommodate the file structures/dependencies of both Softimage and our game assets and it hasn't always been easy. Having a new environment with different rules would put a fresh spin on the problem.


Matt

[Andy Nicholas]

Heh! Yeah right. Like you need me to ;)

[Andy Nicholas]

Yep. Just check out Houdini's digital assets (also known as OTL's). They'll do
much of what you need and more. You can hide and lock stuff up to your heart's
content if you need to be protective about functionality or content. It'll never
be fool proof, but you can at least make it hard to break.

[Matt Lind]

Have you or anybody else tried to write importers/exporters for Houdini?

We would need to write an importer to migrate Softimage data, and an exporter to dump data to our game engine. In softimage, evaluating a mesh is mostly taken care of by the SDK as it evaluates the construction history and hands you the final result depending where in the stack you ask it to evaluate. Since Houdini is procedural and doesn't have a concept of a 'frozen' mesh, how do they handle this?

[Meng-Yang Lu]

Hey Matt,

Spent the afternoon digging a bit.  It's really nicely explained in the HDK with examples.

I would start here as SOPs are the beginnings of all things Houdini.  

http://www.sidefx.com/docs/hdk13.0/_h_d_k__op_basics__sop.html

Followed by Houdini Geometry to show the data structure.  

http://www.sidefx.com/docs/hdk13.0/_h_d_k__geometry__intro.html

And Houdini File System for read/write:

http://www.sidefx.com/docs/hdk13.0/_h_d_k__f_s.html

Look at writing ROPs too as it will let you do sequences of things.  Both could work.  

The way Houdini's geometry work is indeed procedural.  By default, the result of the node tree is held in memory.  However, every node in SOPs has a lock flag that essentially bakes the result of the nodes into the file.  Once a node is locked, everything upstream doesn't matter and it's essentially frozen.  This can make for big .hip files so the workflow is to usually write out the data and read it back in as to not evaluate every time.  When we write out a .geo or .bgeo file, we're essentially stripping the history away.

You can make your node reference Houdini's node path to choose from which point you want to write out.  OR, you can connect the node at any part of the tree and just rely on the input to get your data in GU_Details.  

Doesn't look so scary now that I'm looking at it.  Famous last words...  :P

-Lu

  

[Raffaele Fragapane]

If there is one thing to be said for Houdini is that digital assets (ref models on steroids) set the standard on how to do it right almost as much as Maya sets the standard for how not to do it.

Soft is somewhere in between.
You are very unlikely to find that area of H lacking.