In a mood for sand

[Sifis]

Hi, As we're approaching the summer I think it is the right time to get my hands dirty with sand again. It's a collection of test renders I've made while I was working on a custom sand solver when I decided to move to Houdini about a year and a half ago. Of course with the advent of Houdini 12 flip fluids are much faster plus having access to the built in viscosity and fast point instancing gives a lot more options to play with. Unfortunately at the moment I don't have much time to play with H12 but I hope I 'll fiddle with it very soon. Any comments are welcome!

Edited April 10, 2012 by Sifis

[dbukovec]

incredible! would be nice to see how you achieved this

[br1]

Totally agree with previous post ! It's looking really nice.

It would be great to get some insights and some simulation times as well.

[freaq]

looking great,

*ps request, sandman

[Sifis]

Thank you all guys for your nice comments, When I find some time I'll tidy up the hip files so they are more readable and then I'll post them here so you can check them out.

Edited April 18, 2012 by Sifis

[goldleaf]

Thanks for posting those Sifis! This looks great!

So, when you talk about a custom sand solver, you're just tweaking the FLIP fluids, right? Or is this something implemented in the HDK?

[Sifis]

So, when you talk about a custom sand solver, you're just tweaking the FLIP fluids, right? Or is this something implemented in the HDK?

No it's not an HDK implementation of some kind (I wish I knew HDK programing), it's simply flip fluids with the help of a SOP solver connected in the fluid solver.

[nieming]

great job love it

[thinkinmonkey]

Simply amazing!

I like all the simulations, but the last one, the "sand penguins", is incredible.

[anupamd]

Brilliant work...you nailed the look.. this is really great. Sopsolvers.. so very powerful! eagerly awaiting your hipfile!

[magneto]

Amazing work man, respect. Tonite we will dine in hell after all

[nito]

yeah would love to see the scene file....... love the bunny.....great work!!!

[static]

Nice job.

[portdusk]

So, I talked with Iosif on Vimeo, and he told me his basic set-up and I've come up with a solution! This is my set-up, so I don't know if this is how he did it; I also only focused on the sim, not the shaders.

http://youtu.be/oZ8NRrY9x0o

Basically:

1) Do an RBD sim and save out the BGEO sequence.

2) Do a FLIP sim, and use a SOP solver (plugged into the 4th input of the FLIP solver) to override the FLIP velocity

3) Use point clouds to lookup RBD velocities from the baked out BGEO sequence.

So, that's essentially what's happening, how it actually gets done is kinda complicated. The real trick was getting the FLIP particles to follow the RBD piece that they're inside. I used point color to connect the FLIP particles to the RBD particles, but you could use any attribute. I went with color because you can just use the voronoi fracture SOP to colorize your separate pieces.

Inside the SOP solver, it's not terribly complicated, it's just a VOPSOP. Inside the VOPSOP is where the magic happens. Iosif told me that he used point clouds, so I went down that route as well, and it ended up working quite well.

In the above screen cap, you can see a pcopen, with a pcitterate going into a while loop. For more info on point clouds, I highly recommend Peter Quint's tutorial. I'm using a constant "velholder" as a simple variable to hold the velocities collected during the while loop, just so you can average them together. The antigravity is another constant which is just negative gravity...it's kinda hacky cause I'm just canceling out the gravity node at the end of the autodop network (I'm sure there's a more elegant way to get that done). The switch at the end takes in the input point velocity (the FLIP fluid motion). My setup is just a simple keyframed switch between FLIP motion and RBD motion, but you could control it with a ramp, with the SDF from a fluid sim, etc.

Here's the inside of the while loop:

pc_color and FLIP_color are just vector to float nodes. "colors_are_equal" is an "and" node. All that's doing is looking at the RGB channels from the point cloud point (pc_color) and the FLIP particle color (FLIP_color), and if they're not equal it returns false, which causes the two-way switch to use the input velocity.

"pcimport_vel" is a pcimport node and it's looking up the "v" channel.

Whew! Lots of words... I'd upload the HIP file, but to really see it working you need the whole baked out BGEO sequence, and it's kind of a mess right now. There's probably a lot that could be done a bit more efficiently, but this set-up is working for me right now.

[br1]

Hi travis,

Thanks for your research and explanations.

I'd still be interested in a basic HIP file if you have one lying around, I'm not to worried about baking BGEO sequences, but I'm having some trouble understanding how to override the FLIP velocities with your setup.

Bruno

[muzaffer]

Hi Travis,

 

I have tried your method but no luck, probably missed some parts or doing wrong pipe.

if you upload your hip file would be great

 

cheers

 

Michael