Quoting Tim(“segulin”) from 3DBuzz
———————————————————————–
“The procedural paradigm flows through modelling as everywhere else in Houdini. ……… If you can learn the Side Effects procedural mindset and model in SOPs you can produce not just geometry but………………..
———————————————————————–

I really liked Tim's description, it's encouraging to know that Houdini uses a whole different ”Mindset“ than what I'm used to. I've been through that before with Parametric CAD software. At first I thought it made no sense at all, but after learning the mindset, there is absolutly no better way to work.

That said, can anyone point us ”noobies“ to a good mindset description. So far Tim's post has come closest to something that will ”click“ in my head, but he wasn't trying to explain the mindset, he was just letting us know it's different.

I need a really simple but clear explination of the ”Houdini Mindset"

Any comments or links would be appreciated.

You can not tell it, You must feel it

i can only talk for myself, but keep trying and pluging nodes read the docs when You see a node that seems interesting or unknown, check the various platforms for example files to see the work of experienced users and don't stop doing it. Sooner or later it will click very loud (and often).

Martin

I need a really simple but clear explination of the “Houdini Mindset”

It's no mindset. It's the exact opposite. Do what you want. The other software packages need a mindset. You better have a mindset if you live in a box!

No Fear!

I'm serious. Way way back in the stone age of CG I was a, cough, hack, Pow$# Ani##$)# user. Lots of fun but then I touched Prisms. No more saving versions of files at critical points in a network. No more worrying about an undoable action. No more multiple stabs at tools with repeated undo's. I could shuffle modelling steps as freely as breathing in Action/Prisms. If things broke, the recipe was right there for me to rework to make things right again. Instead of worrying about a step, you can try tens, make that hundreds of options if you want.


No Fear of loosing your work for a misplaced step.
No Fear to experiment.
No Fear to shit on geometry and work it back to genius.
No Fear to wind out really complicated parametric relationships with massive amounts of data. Stays predictable.
No Fear of using tubes, spheres and grids to work up complicated workflows only to wait for the Modellers to get their act together and send the final geometry and voila, done.
No Fear of doing complicated things ‘cause you DON’T NEED TO CODE your solution! Only need to get the ideas understood and in place. Then there's bound to be a dozen ways to do it. With time, you will know the most efficient way.
No Fear of doing it the way you want it done. Everyone has their own style.

Hope that get's you in the mindset. I would expect that every other Houdini user has their own take on this.

Now get off your rear and get on it!

You'll know you're in the zone when you have those technicolor dreams of wiring up networks to solve problems in your sleep.

Both replys so far are pointing in the same direction which is great. And I can see there is a huge advantage to working this way. It sounds great especially if I just want to experiment and play and see what I come up with.

But…. If I have a very specific idea in mind, something not easilt built from primitives, how do I learn where to start?

Don't get me wrong, I know I'm a beginer, and I don't expect to be doing great work anytime soon.

I'm just trying to get a feel for how to aproach some of the ideas cluttering up my head.

the same way you'd approach it in any package, I'd get a basic component working, then the next component, then the next component. It's probably better to get things working in pieces.

This approach is particularly good in Houdini though because of Digital Assets, which is pretty much your own operator/node. Once those nodes are made to do the parts you want than the job gets a lot easier.

Unfortunately there is a drawback though, once you get used to using digital assets you'll want to construct one for everything when something similar might be in the default interface, so it is good to do some background resurch with the default stuff first. I made a DA for a 3dsmax-like polygon sphere the other day (took quite a few hours) only to discover that the “mesh” option for the sphere was exactly the same thing … OOps.

Personally I would pick something really easy to make, like something laying on your desk, and then throw out any pre-conceptions of how you “should” do it and think about how you would “like” to do it. You might get stuck straight away so then ask questions and you will probably get several suggestions of ways to go, then just pick one that appeals and get stuck in.
Another idea would be to just start plopping down sops and clicking on the help “?” icon and loading up example files, that will get you a good idea of how modular Houdini can be. Maybe then try combining a few examples to make something bigger, maybe just an abstract thing that gets you into the idea of what a network can be.
It's depends on how your mind works too, some people like to work in a linear way, I know Jeff has even built his own set of sops (yes you too can easily do it) so that he can work just by adding one after another with no branching. Me , I like to build models up in small patches and then merge all the parts together at the end in a more of a tree like manner.

Here's an image I'm working on at the moment and the another one that shows the network layout for the spanner. Now I'm sure a lot of people would prefer to model something like that just by using a box, polysplit, and edit sops but I tend to use all sorts of things and just use polysplits and edit sops for small tweaks.

it's encouraging to know that Houdini uses a whole different “Mindset”

I don't mean to _discourage_ you, but Houdini doesn't really require any other type of mindset than any other 3d program. People say stupid crap like that all the time, but they're just saying that for complete n0obs. About 95% of houdini works very similarly to the main 3D programs if not identically to the others. In fact, many people on this forum constantly defend houdini saying, “you can do that in houdini already, it's only 46 steps…”. The only exception is that houdini doesn't “think” for the user, so you actually have to know what you're doing each step of the way in order to do something right. But if you actually know what you're doing in xxx 3D program, you'll find that it's basically the same as it is in houdini, for most aspects of 3D, no different “mind” required, just more experience.

If you wanna learn houdini, the best resource is to watch (more) training videos and work alongside them. The 3dbuzz videos are good, but these are much better and more detailed. And as an added bonus, they double as a sleeping pill or two or three… thousand… pills…

http://odforce.net/downloads/videos/v6/ [odforce.net]

the “mindset” a lot of people might be referring to would be the mindset that would normally be scripting in other applications .. which would be reserved for scripting people.

In Houdini everyone gets to enjoy the fun.

This is just my personal observation, but another thing that might require a different mindset is that everything in a more mainstream (see the thread a few posts down) 3D program is typically based around the idea of an “object.” In Houdini it's much more abstract than that and it's more centered around the idea of a network, containing many building blocks of graphical components, not even limited to 3D graphics (cops, chops).

I want to thank everyone for all the great input.

Don't worry, I've already been watching the available videos, and have tried out some of the included tutorials and demo networks.

So far it looks like the most difficult part, as with learning any new software, is going to be figuring out which tools do what. Something like polyface>extrude in Maya is more than likely called something different in Houdini. This is expected, but frustrating none the less.

One thing so far that I can't figure out is, the connections within a network from one node to another aren't labeled, this makes it difficult to understand what attribute in one node is connected to what attribute in the next node. Mouseover “tool-tips” would be an excellent addition to this software.

Since there aren't any labels, how does one find the details of a particular connection? Since the application is network based, and the networks are the key to the workflow, I really expect this to be in the first tutorial.

Anyway, I'm having a lot of fun playing around even though I have no idea what I'm doing.

Thanks again everyone, I promise to try not to be a nuisance.

Hey Don,
With regards to connections, it's simpler than that. In SOPs, _all_ geometry , including all attributes, is passed from one node to the next, full stop. In CHOPs, all data (whatever that data may be) is passed from one node to the next, etc etc. So it's really simple actually. If you want to see what attributes are on a piece of geometry at any SOP, simply MMB on the SOP. If you want to see what the values of the attributes are on a piece of geometry, RMB on the SOP and select Spreadsheet.
If you want to work on a subset of your geometry there are many ways to do that, but by default in a simple SOP chain, it's just one bit of geometry passed from one SOP to the next.

Cheers,

peter B

I thought about this last night & the first thing that came to mind is Lego.

Given the same box of Lego, every Houdini user will build something different with it. You can use the nodes to make something complicated or simple but you build it yourself. This is better than some pre-packaged thing you buy off the shelf but you can't modify it easily or painfully.

Cheers!
steven

Personally, I've always explained the networks as nodes that modify particular *data*. So for any given context, there's only 1 data type that flows through the connections, thus no need to further label them.

Objects -> transform matrices
SOPs -> geometry (3D) data
POPs -> point positions
CHOPs -> 1D data
COPs -> images (2D data)

Also note the terminology change from other packages. In some other packages, “Attributes” (or “Tags” in some cases) really mean “Parameters” in Houdini. In Houdini, “Attributes” are extra data attached to the main data (like point colours which are attached to every point).

edward
Personally, I've always explained the networks as nodes that modify particular *data*. So for any given context, there's only 1 data type that flows through the connections, thus no need to further label them.

Objects -> transform matrices
SOPs -> geometry (3D) data
POPs -> point positions
CHOPs -> 1D data
COPs -> images (2D data)

I don't know whether this is a good sign or not but this is how I view Houdini too.

Although I would say POPs is a iterative version of SOPs.

how would you guys describe DOPs?

Vodka hangover?

andrewlowell
how would you guys describe DOPs?

Simulation states.

andrewlowell
this is just my personal observation, but another thing that might require a different mindset is that everything in a more mainstream 3D program is typically based around the idea of an “object.” In Houdini it's much more abstract than that and it's more centered around the idea of a network, containing many building blocks of graphical components, not even limited to 3D graphics (cops, chops).

I understand where you're coming from but you mentioned cops as an example and that's a perfect example for the statement I was making when I said that virtually all 3d programs (or 2d programs in the case of cops) work basically the same. Pick any node based compositing program: shake, nuke, fusion or even combustion and compared to cops, the workflow is identical. Yea, it may be a different interface from one to the other, but the same methods apply. The nodes are often based on the exact same algorithms and will even have the same names in many cases. Houdini is a little bit different when it comes to 3d programs because it is a little bit more unconventional and open but the same general rules apply, same names, same operations, same from one program to another. This idea that houdini “uses a whole different mindset” is just a buncha bologne. I've heard of houdini being referred to as “alien tech” lol. This idea houdini is insane or extremely different than other programs is only hurting its image in the 3d marketplace. If sidefx is gonna sell houdini to studios (so I can finally start using it) it needs to be seen as a competitive product, not some desparately different tool that needs a god to command.

Sitting down with a reasonably intelligent person for about 5 minutes and all the “alien tech” goes away. Really, this is just about someone who “learns 3D” from a particular package and then is flummoxed when confronted with something that approachs things differently. You can't always have a one-on-one with a patient and educated teacher, of course, so that's where tutorials, introductions and documentation enter into it. That's always been Houdini's weakest link IMHO. For that matter, SESI's(Prisms before it). There's been some strides, but not enough.

I got the procedural “aha!” way back in Prisms, but I remember the block I had before that, coming from Alias. I just didn't grok those structurally complicated SOP lists(you don't want to know - this was before networks and nodes - Animal Logic's “Eddie” was just a gleam in some programmer's eye ). It was one particular demo tape, done by one Dave Geldart, that showed something as simple as copying rotating gears to points on a sphere that absolutely floored me. “Aha! Those SOPs! Data is flowing through them, it applies a process, then passes it on…I GET IT!”.

Might make me look like an idiot now, but it's the truth. All I needed was someone explaining it “the right way”.

Cheers,

J.C.

I started on POV-Ray, which didn't have an interface … just script .. pretty much forced to work procedurally, if or for loop for everything.

Once I started using POV-Ray for commercial projects it quickly became very cumbersome and once I discovered Maya/Max I quickly switched over and did most things much more efficiently … however, I always thought something was missing in these major 3D apps until I bumped into Houdini and gave it a serious look.

After that … all the pov-ray knowledge that was hiding somewhere came back. I know it's very possible to use Houdini in the same way as a maya/max or to use maxscript/mel in the same way as Houdini, but I do think they are very different, which is what makes Houdini very refreshing for me at least.