danwood82

There's really no “fudge factors” in Houdini FLIP fluids, as you might be used to with Realflow. You should be aiming to simulate all fluid scenes at their true, realistic metric scale, otherwise gravity and other forces simply won't add up properly. If the nature of the sim feels off to you, then it's likely a problem elsewhere, not because large scale sims inherantly look better somehow.

I mean, large scale sims *do* tend to be more forgiving, by their very nature of being relatively slow moving compared to their grid size/particle separation, but there's really nothing about that look which you can translate to a small sim without just turning it into something it isn't.

A good starting point is to consider this: At a smaller scale, gravity doesn't change, so it will naturally be accelerating fluids across far more grid cells per frame, due to the grid cells being smaller. FLIP breaks down if you try to have it travel through too many grid cells in a single timestep… so typically even just for a glass of water sloshing around, you'll need at least 3-4 substeps set on the FLIP Solver… where a larger sim can happily get away with 1 in most cases. For an animating glass, I've had to push it up to 12-16 substeps to keep it under control.

You should also try to avoid low particle counts in general. You may think a smaller scale fluid will get away with less particles than a large one, but you're usually viewing it from a much more critical point of view too, so you need to push the particle separation right down until you're using at least a few hundred-thousand particles, if not a couple of million. The more the better really… it's a trade off against solve speed obviously, but in general, you can never have too much resolution in a fluid sim… certainly not within the tight bounds of current PC hardware. Max the resolution as much as possible within your project's time constraints.

The UI issues can certainly be a problem sometimes I'd admit (although a LOT of them are very much improved in Houdini 14)

But when it comes to nodes not functioning correctly - well, if Houdini has taught me one thing over the years, it's that if you think there's a bug in functionality, check twice, check three times, and check again… because it almost always turns out to be something stupid I did. Really, compared to every other 3D package I've used, I've never come across one where the core logic behind everything was as consistently sound and dependable as in Houdini.

It's a complicated package. It pretty much allows you to do anything imaginable - more akin to a programming language like C++ than to a conventional 3D package. But likewise it would be like saying C++ was buggy and broken. C++ *can* yield a buggy and broken program, but usually only because of flaws in the implementation you've come up with.

I know there are bugs, I don't presume Houdini to be perfect, but seriously, always triple-check your own methodology first. I can't count the number of times I've gotten frustrated with Houdini only to end up feeling stupid when I've realised it was something I did wrong.

That's absolutely stunning! Fantastic work, and interesting to know you used Houdini. How much of the design process was it used for?