Rain

[georgi.zhekov]

Hey,

I'm working on a sample scene that should help. Will share it with you as soon as I have something.

[glorybound]

That would be awesome!!!!!

[georgi.zhekov]

Hey Bobby,

You can find a link to two rain setups - the first one I shared a few days ago, which is more suitable for covering the whole house with rain and a second one which is intended to work for closeups.

You can totally combine the two by using 2 Phoenix grids.

The closeup one is using a lot higher grid resolution - this it is slower to calculate, but should look much better up close. Here is a preview of how this one looks - https://youtu.be/f_xKiydgHLg

You can get the scenes from here - https://drive.google.com/drive/folde...usp=share_link


In both scenes I hid all the objects that seem irrelevant to the sim - if you don't want an object to interact with the liquid, it's better to hide it during the simulation or add it in the Exclude list of the simulator (in the Scene interaction rollout).

I have limited the size of the grid to just a portion of the roof so that it sims faster - feel free to adjust the Grid size from the Grid rollout to cover the parts you're interested in.

I already listed the key settings I used for the first shot in my previous post.

For the closeup shot I used a regular box as an emitter for the liquid as it was easier for me to control without having to play with pFlow. In the Liquid Source settings I just added the box, reduced the Outgoing velocity and set the polygon ID to 2 - this way only the bottom part of the box emits liquid.

I'm attaching a screenshot of my settings in the Dynamics rollout:

The key options to take into account are

- the Steps Per Frame - if the liquid is moving too fast you might need to compensate for that by increasing the steps, this will slow down the sim time proportionally so be careful.
- Surface tension - here I used Droplet Formation of 1 to make the liquid form droplets and reduced the droplet radius to 2 so that they are smaller.
- Sticky liquid - I increased this to 0.6 so that the water sticks to the edges a bit before falling down. Increasing the option would make things sticker and vice versa.

For this setup I have also created two additional nodes - first a Body Force that pulls the liquid to the gutter so that liquid will get inside of the opening - you can probably do this without a Body Force, but you will need a bit more grid resolution and you have to nail down the right amount of liquid so I decided to take the safe route here.

The second node is a Particle Tuner which makes the Body Force take effect only near the gutter - it measures the distance to the Gutter and only the liquid that is close to the gutter will be affected by the Body Force. Without the Particle Tuner all of the liquid will be pulled by the Body Force and we don't want that in this case.

A really important thing to note regarding every simulation you make (not only in this scene, but in every scene you make) - make sure to use proper closed geometry (no single face geo like planes, no open edges, no overlapping faces etc.). You can use the STL check modifier to verify if the geo is good.
If you're not using clean geometry the sim might not behave properly and unexpected things might happen. In your scene the gutter is a problematic geo and it works by chance I guess.

If an object will interact with the sim - make sure to use clean shelled geo for it.

I think this is pretty much it.

I hope it helps!

[glorybound]

How exciting! I can't wait to check it out.

[glorybound]

What a pain in the butt! I didn’t realize how difficult this small task would be. If I do a small area of my roof (1’X1’), it looks outstanding. Expand that to a 10’X10’ area, and I run out of resources. I am not sure what memory it wants, since I am not seeing my machine peak (47%), but I am getting an out of memory error. I am decreasing the resolution, but the process is slow. I have to wait about an hour before I see anything, and before I get an error.

[fixeighted]

Welcome to the wonderful world of fluid simulation...well, anything simulation really

Hopefully the guys will be able to troubleshoot and suggest optimisations for what yoope so.

[glorybound]

You see these real-time engines and they flip a switch to get rain. I suppose the rain in those are more of a screen overlay and things don’t actually interact with the environments. I think I have to think about a lot of smoke-and mirrors to get this done.

[Joelaff]

For the simulator handling the roof you can rotate it to line it up with the roof. That way it doesn't have to be very tall and saves a ton of voxels == memory.

[fixeighted]

Yeah that's true. When I was playing with this I imagined a solution which tested for unused voxels and deleted them to return memory.
That is likely magic of the highest order and is unachievable, yet seems like a reasonable thought

[Joelaff]

There do exist sparse volumes (like a sparse array, where only used voxels take up significant memory-- there is a tiny overhead of course), like in VDB, but not in Phoenix at this point.

[fixeighted]

Ah yes, I recently was looking at something using sparse...stuff, but forgot about it, so that maybe was
subconsciously what I was thinking...I guess.

[glorybound]

When done, do I collapse my simulation? I got everything looking good, MAX crashed when I moved something, and now it looks ike I have to run it again.

[Svetlin.Nikolov]

Ah, are the simulated AUR cache files there on the disk? If so, you can point to them from the Input rollout if you won't be running the simulation again and need them only for rendering, or from the Output rollout if you would need to simulate more.

[Svetlin.Nikolov]

Regarding sparse sims - they are about 30% slower than a dense grid of the same size. We measured this with VDBs compared to AUR, and also with AUR compared to our own prototype sparse implementation. So in order for a sparse simulation to make sense, it would need at least 30% of the grid volume to be unused, which is rarely the case because even if you don't see the velocities, they make a hell of a difference to the end result of the simulation. So a good example of a practical case where sparse sims would help would be a T-shaped simulation, such as a rocket launch.

[glorybound]

Ah, are the simulated AUR cache files there on the disk? If so, you can point to them from the Input rollout if you won't be running the simulation again and need them only for rendering, or from the Output rollout if you would need to simulate more.

I think it is being saved $(same_as_output)