New Houdini Book - looking for input

   11645   12   3
User Avatar
Member
557 posts
Joined: July 2005
Offline
I have a agreement to produce a Houdini book, to be published later this year. This will be very different from Will Cunningham's book. Mine is meant to be a kind of “Houdini Hacks”, a compilation of (possibly) obscure but useful techniques for wringing the most out of Houdini. The target audience is not beginners, but intermediate-to-advanced Houdini users.

To make this clearer, I have attached a short chapter sample that the publishers saw.

The reason I am telling you this is that I am looking for help from the Houdini community. I want to collect useful tips from users on any Houdini subject - modeling, particles, dynamics, shaders, scripting, rendering, whatever. These should be simple idiomatic uses of individual houdini features, not 200-node extravaganzas.

In exchange for your help, I can make this stupendous offer: if I use something you contribute, I will include your name and brief bio in the contributor's section (see the O'Reilly Linux Hacks book as an example of this), and you will get a copy of the book.

To save clutter, feel free to respond to me directly: craig@sidefx.com either with tips or just with questions.

Thanks very much!

Attachments:
UI_chapter_sample.doc.gz (197.4 KB)

User Avatar
Member
4140 posts
Joined: July 2005
Offline
What a very cool idea! Nice to hear you've got an interested publisher. Request noted.

Cheers,

J.C.
John Coldrick
User Avatar
Member
506 posts
Joined: July 2005
Offline
great! … another book for my next xmas then

cheers and go on!!..
JcN
VisualCortexLab Ltd :: www.visualcortexlab.com
User Avatar
Member
4132 posts
Joined: July 2005
Offline
craig
Mine is meant to be a kind of “Houdini Hacks”, a compilation of (possibly) obscure but useful techniques for wringing the most out of Houdini. The target audience is not beginners, but intermediate-to-advanced Houdini users.

With Houdini there are a tons of different methods that in the end give the same result. One of the things that is most daunting to new users, (and vets too), is which method do I pick?

For example, a lot of the smaller POP & SOP network chains can have their functionality reproduced in a single VEX node. The advantage is you cut down on the number of nodes, (and memory) and in some cases get a nice speed improvement from the threading in VEX. At first glance this seems great, less memory and faster, but the down side is you now have the additional overhead of your VEX code or VOP network which has to be maintained. Sometimes the slower/straight forward approach is better in a studio environment where you might have to hand-off your work. Also just because an approach is super flexible doesn't mean it is best approach.

Back to the point, when you are describing the different hacks, it would be really nice to see some pros and cons to using that hack.

Is it more memory efficient?
Is it faster? (For small data sets? For large?)
Is it easy to maintain?
Stuff like that.
if(coffees<2,round(float),float)
User Avatar
Member
412 posts
Joined: July 2005
Offline
This is awesome craig.. A great format too..
Dave Quirus
User Avatar
Member
6769 posts
Joined: July 2005
Offline
A good trick that I've been meaning to put one the odwiki somewhere is to use a Constant CHOP to store common subexpressions and then use a chop() expression to reference the result. This improves speed considerably for slow expressions that are used in multiple places.
User Avatar
Member
21 posts
Joined:
Offline
Cool, sent ya some tips in your email. Let me know if they are any good.
User Avatar
Member
2196 posts
Joined: July 2005
Offline
I like it, but it should be called “stuff that should be in the help but either it isn't there or you didn't read it” Your title is snappier though.
I'll get my thinking cap on….
The trick is finding just the right hammer for every screw
User Avatar
Member
557 posts
Joined: July 2005
Offline
it should be called “stuff that should be in the help but either it isn't there or you didn't read it”

True enough. The whole thing comes from me seeing lots of interesting bits and bobs go by (including in internal SESI stuff, which is definitely cheating) and thinking “Hey! I never knew that!”

It seemed unfair that all these nuggets should be hidden away.

And something about human nature tells me that, even if all this stuff were in the help docs, there would still be an audience for a book like this… :wink:
User Avatar
Member
2196 posts
Joined: July 2005
Offline
I know what you mean, I made it a habit over the years of saving emails from the list that mention these types of hacks even if I didn't think them relevant to what I was doing. i'll check through them and see if there is anything good in there.
The trick is finding just the right hammer for every screw
User Avatar
Member
47 posts
Joined: July 2005
Offline
I like the houdini hacks idea for a book
One of the most useful books I've read on software
has been the Killer Tips for Maya 5 and 6.
This sounds like it will just as much, if not more fun than those.
WhooHoo!!!
Congrats!!

Lyn Caudle
Visual Effects Supervisor
Janimation
www.janimation.com
lyn@janimation.com
User Avatar
Member
220 posts
Joined: July 2005
Offline
Will you be including some HDK code (assuming someone sends you some)?
User Avatar
Member
557 posts
Joined: July 2005
Offline
I wasn't going to, mainly because the prospect of searching out those kinds of examples is so daunting. Also, my assumption has been that with the HDK, you're mainly going to be pointing out to people things like “before you can do this, you have to make these 3 other calls.” Somehow, that doesn't feel like a tip or a trick, it just feels like how you get it working.

But if If I had some items, I would probably find a way to include them. Send 'em on in. And who knows, you may inspire me to generate some of my own.
  • Quick Links