Color in FLIP sims - milk pour into tea

[Stephen Moroz]

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!

[ParticleSkull]

Hey Stephen,

This is probably not the best approach but I think it's a starting point. You can make all the caches on the OUT context (using the merge node)

Tea.Flip.Pyro_v1.01.hiplc

[Stephen Moroz]

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

[ParticleSkull]

Cool! pls update the topic with news

[Stephen Moroz]

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?

 

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

Edited July 5, 2018 by Stephen Moroz

[Stephen Moroz]

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:

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

[nigelgardiner]

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 July 14, 2018 by nigelgardiner
forgot the obvious.

[ParticleSkull]

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

[Stephen Moroz]

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:

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?

[nigelgardiner]

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.

 

[Stephen Moroz]

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:

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!

[chrisdunham95]

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. 

 

 

[Stephen Moroz]

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

[Stephen Moroz]

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

[Jesper Rahlff]

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.

[Stephen Moroz]

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  

[Stephen Moroz]

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

[sfpar]

please can I get a hip for this