Scott Keating


About Me

Not Specified
Not Specified

Scott Keating is a production specialist at SideFX specializing in the user experience needs of Houdini artists. He is also an award-winning commercial illustrator, designer, and comic-book artist and his work has been published worldwide, in magazines, books, comics, and commercial products.


My Talks

obj-image SIGGRAPH
Lighting and Rendering
obj-image SIGGRAPH
Rigging and Muscles
obj-image GDC
Houdini 16 for Games
obj-image GDC
Thinking Procedurally
obj-image VFX Festival
Intro to VFX
obj-image Utrecht
Houdini for VR

My Tutorials

obj-image Beginner
Mantra User Guide
obj-image Beginner
PyroFX | Volcano
obj-image Beginner
Mantra Waterfall Render
obj-image Intermediate
FLIP Fluid Waterfall

Recent Forum Posts

What's with the new fuse/snap SOPs? March 15, 2019, 6:53 p.m.

I understand the need to have the “group” and “target group” distinction and it does confer procedural power to the new SOP. I want that and I need it.
So in order to not give only flak, here's some constructive suggestions on how to not totally ignore the viewport functionality needed in direct modeling.
So, “group”(G) acts as both “target” and “source” when “target group”(TG) is disabled (default). So having points designated only to G (TG off) will produce something based on w/e is set by “output positions” (default - average value), like here:

Image Not Found

When the latter is enabled, w/e is in G it will snap/fuse to TG. This makes “output positions” rule obsolete, since G will snap/fuse to TG, for the case in which TG has only one point.

Image Not Found

For TG with multiple points, each G point will look for the nearest TG point and as the “snap distace” increases, they will ultimetely collapse into a single TG point. This is harder to show in images, but you can surely test it out.

With these in mind, perhaps having a selection prompt, as many other shelf tools have, is the best way to deal with these:
- select one or a few points, call Fuse SOP and auto-assign that to G
- press enter (i still don't know why Return is still used for these instead of shift+RMB, or any thing else that doesn't require moving the hand from one side of the kb to the other) to select TG, if any
- enter again to commit on G selection only
I might haven't thought this through very thoroughly, so issues could exist with this, but it's no excuse to be left with the current abysmal snap/fuse workflow in the viewport.

Yup, very reasonable. If you haven't created an RFE, please do.


Camera pan with a "look at" constraint Oct. 29, 2018, 12:21 p.m.

Houdini 17 will have a new option to continuously export the view changes to the camera so you don't get that snapping back to your camera interest on mouse release. This option effectively just applies the constraint after each processed mouse motion to give a smooth motion. I don't know whether this specifically addresses your particular problem, but I thought I'd mention it.

Hello Ondrej,

did this ever make it into H17? If so, I have a hard time finding it.

Thank you


In the viewport, under the camera menu ( The icon which says ‘no cam’ by default ), there is an option near the bottom of the menu called ‘Export View Continuously’. This is the feature that Ondrej had mentioned previously.

Hope it helps!


Align handles to geometry Oct. 18, 2018, 4:50 p.m.

The volatility aspect seems therefore linked to the feature itself, not a specific key. A “make multi-snapping volatile” RFE is in order.

That's right, there are certain ‘states’ which are volatile, meaning that they can be activated by pressing and holding a hotkey, or ‘tapping’ the hotkey to move into the state in temporary way.

A similar mode for the attach/detach handle operation is in development.

A “make multi-snapping volatile” RFE is in order.

This feature is on the list of things which we would like to tackle in future updates.

You keep inviting users into alpha/beta that spend 90% of their time in wranglers and then probably read in astonishment “mean” posts like this from “frustrated” users.

I'm not quite sure where you got the impression that we are astonished by ‘mean posts from frustrated users’. We generally understand the source of the criticism and are sympathetic to the frustrations felt by users. Arguments presented by users are often used internally to try to guide development efforts to help alleviate pain points. That said, development time and resources are limited, and things that may seem like easy fixes from the outside are not always that simple when it comes to actually implementing them. Something like the volatile states mentioned above were part of the most recent effort to update some of the ways a user can interact with Houdini. This process will continue into the future, and hopefully things improve across the board over time.

If I don't classify as a devoted user that tries to contribute with constructive criticism and feedback, judging by the number of RFEs and posts documented with pics and gifs, in the limited field that I'm competent, then fuck whatever is considered a devoted user around here!

Alpha/Beta access is necessarily limited due to the resources required to track and respond to those users who have been given access. It is likely that there are ‘devoted users’ who are not part of the alpha/beta process. We try to include users from different disciplines as much as possible to make sure we get useful feedback on ‘in development’ features - that includes modelers, riggers, animators, etc. I seem to recall that you were part of this process for the release of Houdini 14, but I could be wrong about that.

I don't think there were any questions in your last post, but hopefully this response helps clarify anything that was left unasked.