and in the network view (that's the one with your nifty node tree), NEVER EVER fail to

HIT Cmd-B

(that's on the Mac, its something else on other computing devices but you get the idea)

and BOOM, the magic of how your genius brain works in one EASY TO SEE screen that is super useful for screen grabs and other such wizardry!

Cheers

Moin,

I guess you mean the function to enlarge the networkview-pane to “full size”, which is CTRL+B on Windows (and probably on Linux)? While that is nice for displaying a complex network view, it may not be what you need in a tutorial that shows what the nodes actually *do* (in the perspective view).

Yet, you are right of course, showing how the full network looks like quite often would be helpful in tutorials.

Since I want to produce Houdini tutorials (and have started with some small “make your transition easier” ones on Vimeo), I would love to see more hints *and* *wishes* in this thread about what people would *like* to see in tutorials, what they hate, what they consider good practice!


Marc

I am really thankful for anyone who recorded a tutorial on Houdini in recent years. Without people sharing their knowledge, learning Houdini would be really hard.

Although most tuts on Houdini are well done, here is my personal dont do it-list for tutorial authors:

- not presenting the result in the beginning
- starting tutorials half way in, not starting from scratch
- using shelf-tools and not explaining what has been set up
- left-outs/jumping, correcting mistakes while not recording
- wasting screen real estate for unused panels (eg shelf tools)
- zooming too far in the node view so you cant see the context
- zooming too far out so you cant read the nodes names
- recording at high resolution, so you cant read codes and expressions
- confusing scribbles
- bad voice recording
- webinars

Moin, Konstantin,

*that* is a *very* helpful list, thank you! I agree with most points 100%, with some 87% and with one I have an issue:

- webinars ;-)

What I don't get is this: While I personally find webinars fascinating, because they usually show you “real world” usecases instead of just “artists playing around”, most webinars use sub-standard tech for recording. It would be so easy to record audio AND video on the presenter's system while doing the screencast through some backdoor hack (Skype or whatever), so that the life audience can experience the full bootleg quality of scrappy sound and video, while those willing to wait for Vimeo-uploads get a high quality, maybe even cleaned up version (I hereby volunteer to do audio cleanup and video editing for Houdini webinars).
So … I wouldn't “ban” webinars, I would just ask for modern tech to be used for the recording.

My personal “don'ts” (*additionally* to yours)

- show only “artistic” use of tools (instead, please, EXPLAIN what the tools do and WHY you chose one over another)
- show hours and hours of breathtakingly boring fiddling with unimportant (read: artistic) corrections (instead show one, two minutes of fiddling, then do a timelapse or edit the video, explaining what you did in a 10-second-spotlight)
- use outworldish third software to fix problems if the tutorial is said to be about solving the problem in the “on topic” software (like using Photoshop to correct texture maps when the video is about correcting texture maps in Mari)
- edit out bugs in the software and only show workarounds (instead, please, DO SHOW the bugs, it is well possible that those bugs have been removed later and viewers of the tutorial can live without the workaround. But, please, also show the workaround)
- pretend that the software you are showcasing is “the best” and “quite perfect” when the rest of the tutorial clearly shows that it is overly complicated to get the results you are after and it would take you only seconds to do the same in a specialized tool (instead state that you are only making a point that it “is possible to do it here, too, but only if you just got a divorce and have time to waste”)
- talk too slow or not at all
- smack, slurp, cough, lisp
- talk about a single vertice. (just call the bugger by its real name: Vertex.)

Marc

malbrecht
Moin,

I guess you mean the function to enlarge the networkview-pane to “full size”, which is CTRL+B on Windows (and probably on Linux)? While that is nice for displaying a complex network view, it may not be what you need in a tutorial that shows what the nodes actually *do* (in the perspective view).

Yet, you are right of course, showing how the full network looks like quite often would be helpful in tutorials.

Since I want to produce Houdini tutorials (and have started with some small “make your transition easier” ones on Vimeo), I would love to see more hints *and* *wishes* in this thread about what people would *like* to see in tutorials, what they hate, what they consider good practice!


Marc

I am not suggesting they keep it open, only as appropriate, and definitely at least once with an overview. Even the best authors will keep the node view to a small square in the bottom right as they search for nodes or discuss the setup to come. A bit frustrating.

I just put webinars on the list because i would rather like to see the same people do proper information-packed tutorials. Watching someone drinking coffee while another guy scrubs through his latest projects is probably a nice personal experience, too. Other than that, i agree to the technical part you mentioned.