Hi,

I’ve been playing around, and following some Houdini tutorials for the last couple of weeks. I must say, I am a little conflicted on whether I actually like the program.

My problem is definitely not that the program is too technical or ‘closer to programming than artistry’. My biggest issue is actually that it so far for me does not really live up to the flexibility and logicality I had expected from it…

I am an experienced programmer, and reasonably practiced at making things into formal recipes, algorithms etc. However, I find in Houdini it’s often more knowledge of how to do something, rather than reasoning your way to an approach.

This is due to the fact that the program is quite obscure and inconsistent about many things. Obscure: each node has many hidden features that you need to know to make the most of it. They may listen to specific attribute names, which cause them to set parameters in per point/vertex/etc. basis, suddenly making a simple node infinitely more powerful. Which attributes names are listened to, and which parameter can be set like this is quite a mystery to me, so you kind of happen to stumble upon it in a tutorial, it seems. Or is there a way to show in the software which attributes a node uses for parameter modulation?

Inconsistent: there are many different ways nodes can influence each other. Initially you might think node connections indicate which nodes are affecting each other, but then you have different ways parameters and attributes from different nodes can be referenced, or for example the SOP import in a COPnet, where a SOP is referenced without the SOP out being connected to the COP in. To me, it makes networks feel not clear and clean, unnecessarily hard to understand because it’s too hacky. Not to mention the need to have different coding and expression languages going on, each for their own little purpose…

Lack of flexibility and modularity: rather than being able to grow project by gradually adding more complexity to the node network, it seems that you need to build a network already with each part in mind. For example, if I build a tree network which has some random parameters for branch numbers, angles, etc. Now I want to build a forest of unique trees by scattering it around a terrain, I end up having to do the scattering and tree generation in the same network. I cannot make a ‘black box’ random tree generator, that then gets used by another node to place instances around the terrain.

Alright, time to end my rambling. Hopefully someone can address some of my frustrations and show how to approach the program better.

I feel you! Yes, there’s definitely some inconsistency—no doubt about that. Would I like a program that’s entirely node-based, sleek, and cleanly structured from start to finish? Sure. But that software doesn’t exist at the moment. Houdini is the closest thing to it for 3D creation. However, its quirks eventually stop feeling frustrating and just become part of the workflow. At least that’s been my experience.

Every 3D tool I’ve used (3DS MAX, C4D, Blender, Softimage) has had its own shortcomings and strengths. For me, Houdini’s strengths far outweigh its shortcomings. But of course, everyone has their own preferences.

Cheers,
CYTE

Or is there a way to show in the software which attributes a node uses for parameter modulation?

Unfortunately no. Most of the time it's documented. When it's not documented it's guesswork.

but then you have different ways parameters and attributes from different nodes can be referenced, or for example the SOP import in a COPnet, where a SOP is referenced without the SOP out being connected to the COP in.

Network View -> View -> Show Dependency Links. That's all you can do.

It's a necessarily evil design. If you ever used other node-based software that follows strict 'no ghost link' principal you'll know what I mean. Trust me, things like SOP Import and Object Merge are really really necessary to keep the number of wires manageable.

A programming analogy: they're global variables. Evil, but necessary. Programmers have been reinventing global variables (in names of "config file" or "singleton" or "local database" or...) for decades.

That being said, SideFX definitely should have introduced an "explicit" version of SOP Import. (Yeah one can use some expression to refer to the input of the parent network, but still...)

Not to mention the need to have different coding and expression languages going on, each for their own little purpose…

A sad reality. There is no fix to this (besides abandoning Houdini as a whole). If SideFX introduced a new unified language in H21, it would only make things worse.

I kinda believe they've already made things worse by introducing APEX and OpenCL support into Houdini instead of extending Python/Vex. Unfortunately, what they did might be the quickest way to make the rigging feature and GPU capabilities live.

I cannot make a ‘black box’ random tree generator, that then gets used by another node to place instances around the terrain.

Not sure why though. This very particular case is usually where Houdini shines (despite its stockpiles of drawbacks).

rrrobindr
Which attributes names are listened to

https://www.sidefx.com/docs/houdini/model/attributes.html#attributes [www.sidefx.com]
https://www.sidefx.com/docs/houdini/copy/instanceattrs [www.sidefx.com]
I usually refer to these pages if I ever forget which attribute names Houdini likes for certain things. If a node is ever behaving unexpectedly or you're wondering if a node will pick up a certain attribute it's most likely one of these, particularly the point instance attribs.