Jump to content
Stephen Moroz

Color in FLIP sims - milk pour into tea

Recommended Posts

Hi everyone,

I was thinking of creating a simulation of milk pouring into tea as a showreel piece, but I'm not sure how best to go about it. I have seen people using color in FLIP sims, however in all the examples I have seen, the fluid is shaded to be opaque (like different color paints mixing). In my case though, I'd need to be able to see the milk as it is poured into the tea and see it underneath the surface. Then over time, it needs to change the color of the tea. My best guess would be to simulate the liquid, and then create a separate smoke simulation for under the surface of the water. However I have no idea how I would integrate the two.

Here is a reference video I found:

Any ideas for this would really be appreciated!

Share this post


Link to post
Share on other sites

Hey @ParticleSkull this is super useful, cheers! I've looked through your hip file and this seems like a great place to start. I'll experiment with this method further and see how it goes

Share this post


Link to post
Share on other sites

I've been working on the flip sim but I've come across a strange issue. When I add the milk particles into the mug, the level of the water seems to get lower rather than higher. I've not had much experience with flip sims, so any ideas what might be causing this?

giphy.gif

 

UPDATE: I turned on particle separation in the flip solver and now it's fixed! 

Edited by Stephen Moroz

Share this post


Link to post
Share on other sites

I've gone ahead and modeled the mug and milk carton, and set up a flip sim. However I seem to be having trouble with the milk going through the collision geometry. I've made sure that the collision volume has sufficient width and no holes, but it seems to still go through. Any ideas?

Here is the problem I'm having:

giphy.gif

And here is the collision field, visualized on the flipobject node.

collisionField.thumb.PNG.b504248fcf0eb23309ab1c165a951a40.PNG

Share this post


Link to post
Share on other sites

Hi Stephen

Are your particles going thru your mesh or just your fluid surface. If it's only the fluid surface look to how you're building that, maybe dilation is too much?

Or the resolution of your surfacing mesh is too high - not detailed enough to catch the detailed shape of the fluid as it pours out of the carton?

Oh and check the positioning and definition of your collision volume in relation to the geometry of your milk carton.  The inside surface of the collision volume will need to match perfectly with the inside surface of the milk carton, or at least where it's pouring from.

 

cheers

Nigel.

 

Edited by nigelgardiner
forgot the obvious.
  • Like 2

Share this post


Link to post
Share on other sites

Well noticed, nigel! If it's only the mesh you could also use the Collisions' options in the Regions tab of the Particle Fluid Surface to subtract that part of the mesh

  • Like 1

Share this post


Link to post
Share on other sites

Cheers for the suggestions guys! Unfortunately the actual particles are going through, so it isn't a problem with the surfacing.

I've adjusted the animation of the carton and it seems to have introduced some more problems with the collision:

giphy.gif

I guess I could just cut out the particles that are problematic before surfacing, but I'd rather get it working properly if I can.

At the moment I am generating collision and collisionvel fields in sops and then bringing them into dops using a fluid source node (that way I can cache these fields separately, saving time in the sim) - would it be better to use a static object node instead?

Share this post


Link to post
Share on other sites

I think there are many ways to work with collision volumes but the way I find the most straight forward is to create a vdb volume in sops and then use this as a proxy volume in the static object.  If you turn on the deforming object checkbox it will pick up any animation at the sops level.

If you have particles travelling thru the collision volume then I think it means the particles are travelling too fast in one sub step (time frame?) for the solver to calculate whether or not they are colliding with the collision volume as the particle has already passed thru it.

You can remedy this by increasing the size of your collision volume, make it fatter, and/or increase the solver sub steps.

 

Share this post


Link to post
Share on other sites
On 17/07/2018 at 9:27 AM, nigelgardiner said:

I think there are many ways to work with collision volumes but the way I find the most straight forward is to create a vdb volume in sops and then use this as a proxy volume in the static object.  If you turn on the deforming object checkbox it will pick up any animation at the sops level.

If you have particles travelling thru the collision volume then I think it means the particles are travelling too fast in one sub step (time frame?) for the solver to calculate whether or not they are colliding with the collision volume as the particle has already passed thru it.

You can remedy this by increasing the size of your collision volume, make it fatter, and/or increase the solver sub steps.

 

Hi Nigel,

I tried creating a collision vdb in sops and using it as a proxy volume in the static object, however it seems to make the sim take around 3 times longer. It also has it's own weird collision problems. Here's the result:

giphy.gif

I've just started an internship so I don't have as much time to spend on this now, but I'll try to fix this over the weekend. I'll also put a hip file up, in case anyone can see what I'm doing wrong.

Cheers for the help so far!

Share this post


Link to post
Share on other sites

If you can possibly provide your hipfile man I can take a look and try some things! 

Congrats on the internship too man well deserved :)

Chris. 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
On 25/07/2018 at 2:59 PM, chrisdunham95 said:

If you can possibly provide your hipfile man I can take a look and try some things! 

Congrats on the internship too man well deserved :)

Chris. 

 

 

Thanks Chris! Sorry for the delay in replying to this. I'll see if I can get a hip file up this evening :)

Share this post


Link to post
Share on other sites

Turns out it was just a substep issue! After increasing the substeps, most of the issues disappeared. Cheers for the help guys :)

Share this post


Link to post
Share on other sites

I have had this issue before when working with flip and collisions. I find this often happens when your collision is animated. So a potential work around that has worked for me before, would be to freeze your collision geometry, and bring it in as a static object in your sim, and then add the transform data back onto the static collider with a motion node in your sim referencing the translate and rotation data from your animated geo in sops. This way you should be able to avoid substeps.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
On 31/08/2018 at 1:56 AM, Jesper Rahlff said:

I have had this issue before when working with flip and collisions. I find this often happens when your collision is animated. So a potential work around that has worked for me before, would be to freeze your collision geometry, and bring it in as a static object in your sim, and then add the transform data back onto the static collider with a motion node in your sim referencing the translate and rotation data from your animated geo in sops. This way you should be able to avoid substeps.

Oh wow, I'll have to give this a try! Cheers :) 

Share this post


Link to post
Share on other sites

Yep, adding the motion in DOPs fixed the issue. It now seems perfectly stable with just 1 substep. Thanks so much!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×