Can Houdini do this fluid setup?

[hopbin9]

This is really cool, and I want to give this a try.

http://www.vimeo.com/9746636

Any ideas on what the setup would be for something like that?

Thanks,

[Macha]

Pretty sure somebody versed in dops (hello Bunker!) can do this easily. As a first thought I would try playing with the smoothing and point scale in the flipsolver, and then those ideas from the melting thread a while ago could help. I think the particles used in flip could also be made to stick together and break with an interact pop or something like that (or blend pos and vel in a voppop according to distance). That's the hard part: to make them stop in time so they won't melt together completely.

Another problem I see here is creating a sufficiently clean mesh from it. I always find the particle fluid surfacing so slow when creating hires meshes.

Busy rendering now but I'll have a go at it as soon as I can!

Edited March 18, 2011 by Macha

[bunker]

Yum, what a tasty simulation

I had a quick go at it (about 10mins).

Just changed the particle separation scale to 0.98 ( to make the particles stick a bit more )

and turned on the sticky fluid in the Projection tab. I also did my own "drag" force to

make sure the particles slow down towards the mid height of the cake. ( when Y<0.5 )

Bon appetit

[Macha]

Bunker, I tried various methods and like yours there is one problem that remains: how to stop melting after a certain point. Ideally the fluid should stop moving after some time so that it can retain folding and layering structures. Imagine a hot sugar coating. It would be fluid for a while but then solidify. So you could write shapes onto another layer, or bend and stack them with some but not complete melting.

I would be interested to see a solution for this problem.

[hopbin9]

That's a great start.

I'm going to give this a try, and get back to the thread when I get a chance.

[pclaes]

Bunker, I tried various methods and like yours there is one problem that remains: how to stop melting after a certain point. Ideally the fluid should stop moving after some time so that it can retain folding and layering structures. Imagine a hot sugar coating. It would be fluid for a while but then solidify. So you could write shapes onto another layer, or bend and stack them with some but not complete melting.

I would be interested to see a solution for this problem.

Same trick as the wax, but in reverse... "cool down" your fluid by slowing down the velocity. Multiplying it to zero based on that Cd. The problem is that potentially it will hang in mid air without gravity working on it. At the point where it solidifies it becomes much more like an rbd. Not sure about a clean solution to that yet.

[bunker]

exactly, that's a reversed wax melting effect. since we use a sopSolver it's easy to scatter some points on the cake

and create a "hit" attribute based on proximity. if "hit" > 0, then start cooling the fluid. That fixes the points

floating in mid air. Also, it makes sense: the cake has more friction than air

Same trick as the wax, but in reverse... "cool down" your fluid by slowing down the velocity. Multiplying it to zero based on that Cd. The problem is that potentially it will hang in mid air without gravity working on it. At the point where it solidifies it becomes much more like an rbd. Not sure about a clean solution to that yet.

[varomix]

HI

I did this test like a month ago using flip fluids

I got a better result that I was getting with RF and faster

www.varomix.net/clientx/mixstudio/ChocolateTest_v01.mp4

Please ignore the bad render, I could try adding another layer on

top to see if that sticks

I would say this is more like an elastic sim like a soft body or even a

cloth might work for this

I'll post the hip later

Edited March 20, 2011 by varomix

[bunker]

File gone from my previous post, so here it is again :

creamcake_001.zip

[Nerox]

I'm not trying to crash anyones party or what so ever but I've heavily researched this area of FLIP viscosity. My conclusion is that the current state of the FLIP solver isn't sufficient to create these types of effects. Let me explain why:

Let's start about what's cool about FLIP and why you would like to do viscose type of effects with it.

A# FLIP omits the stacking problem SPH suffers from, it needs far less sub-steps which makes it a very fast solver.

B# Having the world of fields and particles in one solver unlocks a lot of potential

This sounds awesome, so whats the point?

1# Viscosity describes how much a fluid, internally, is willing to flow. The best way to simulate this is by using particle to particle forces, like springs. This is the first problem you run in to because FLIP doesn't have any, which is essentially the power of FLIP in the first place.

2# Like mentioned in this tread, first thing that comes to mind is to multiply the velocity in certain area's. This might work in a test setup or 2 but it just doesn't work in regular effect shots. The reason is there is something as gravity, and when you're scaling the velocity you totally bypass this, which potentially results in fluid stopping in mid air.

3# Ok, well maybe I can get around this by trying to calculate some sort of rigid motion, and then I don't apply my viscosity in those area's. Again this does work in some test setups, but it is very hard so get right and it only works in certain cases, once stressed it fails miserably.

4# What does work is calculating the internal strain / distortion of the fluid, or with other words, the difference in speed and direction between neighbor particles or voxels. You can then use this to slowdown the fluid.

This is the point where I considered my self unbeatable, and figured that this was going to work and I could finally create my flubber jello type of effect :-D

5# I was wrong

6# This is the point where you start to notice the volume loss that FLIP suffers from, luckily this is also cheat-able by playing with the non divergence step.

7# Not to mention the problem when the fluid gets really thin and starts to separate in little blobs.

8# How ever, and this is where my 'epic' adventure ended, that there appears to be an issue with the collisions. What basically happens is that the particles overshoot the point where they're supposed to stop due to collisions which results in jittering fluid which is should be at rest. Which doesn't do any good to the volume preservation.

This is all fine if your simulating a river or a waterfall, but it appears to be really annoying when you're attempting to do viscose fluids. By all means, blurring the velocity field does part of the trick, but if you're being honest you'll just end up with mud.

It would be awesome to have a FLIP á like solver with particle to particle forces or springs. This way you could get around all the issues that SPH has, by using the velocity and non-divergence projection and achieve really nice viscose effects.

@Bunker You are probably familiar with this, but for any one who isn't, when doing this kind of stuff the Gas Field VOP is your friend, this is FLIP, use those fields!

[varomix]

That's why I said that this could be even easier to do using cloth or softbodies , that might work

[pclaes]

Nerox, thanks for contributing, those are some interesting points.

1# Viscosity describes how much a fluid, internally, is willing to flow. The best way to simulate this is by using particle to particle forces, like springs. This is the first problem you run in to because FLIP doesn't have any, which is essentially the power of FLIP in the first place.

Is that true? Especially the "springs" part sounds more like elasticity. In SPH fluids they can break and you get that nice shockwave propagation (like in the Houdini demoreel a few years ago where the piece of dough gets cut by the knife.)

So what is viscosity then?

According to wikipedia ( http://en.wikipedia.org/wiki/Viscosity ):

Viscosity is a measure of the resistance of a fluid which is being deformed by either shear stress or tensile stress. In everyday terms (and for fluids only), viscosity is "thickness" or "internal friction". Thus, water is "thin", having a lower viscosity, while honey is "thick", having a higher viscosity. Put simply, the less viscous the fluid is, the greater its ease of movement (fluidity).[1]

Viscosity describes a fluid's internal resistance to flow and may be thought of as a measure of fluid friction. For example, high-viscosity felsic magma will create a tall, steep stratovolcano, because it cannot flow far before it cools, while low-viscosity mafic lava will create a wide, shallow-sloped shield volcano. All real fluids (except superfluids) have some resistance to stress and therefore are viscous, but a fluid which has no resistance to shear stress is known as an ideal fluid or inviscid fluid.

From that definition I do not get the impression there are much springs involved. I do agree with the inter particle forces though.

2# Like mentioned in this tread, first thing that comes to mind is to multiply the velocity in certain area's. This might work in a test setup or 2 but it just doesn't work in regular effect shots. The reason is there is something as gravity, and when you're scaling the velocity you totally bypass this, which potentially results in fluid stopping in mid air.

Alright, so let's not multiply the veloctiy. How do we extract "the fluid velocity" from the "gravity velocity"... generally a velocity is built up from a combination of forces added together. So perhaps we could subtract the gravity, add some interparticle and per particle forces, and add the gravity back on. How would that work with collisions...?

3# Ok, well maybe I can get around this by trying to calculate some sort of rigid motion, and then I don't apply my viscosity in those area's. Again this does work in some test setups, but it is very hard so get right and it only works in certain cases, once stressed it fails miserably.

4# What does work is calculating the internal strain / distortion of the fluid, or with other words, the difference in speed and direction between neighbor particles or voxels. You can then use this to slowdown the fluid.

8# How ever, and this is where my 'epic' adventure ended, that there appears to be an issue with the collisions. What basically happens is that the particles overshoot the point where they're supposed to stop due to collisions which results in jittering fluid which is should be at rest. Which doesn't do any good to the volume preservation.

I think this is where the solution lies. I have some experience with flocking system and fuzzy logic. I think adjusting the force based on the distance between the particles tends to get rid of this jitter, especially when combined with (non-linear)ramps. It will always move a bit as it is always trying to find an equilibrium between push and pull. This is the difference between a solid and a fluid, no? The particles in a real fluid in the real world are moving too, in a solid they are fixed.

By all means, blurring the velocity field does part of the trick, but if you're being honest you'll just end up with mud.

It would be awesome to have a FLIP á like solver with particle to particle forces or springs. This way you could get around all the issues that SPH has, by using the velocity and non-divergence projection and achieve really nice viscose effects.

This is already possible. In the same way you use a sopsolver in the post solve to reduce the velocity to 0, you can add to the velocity based on a pointcloud lookup to push and pull points.

The problem with the pointcloud approach is that if you were to put a metal plate in between, it would ignore it and try to attract towards the fluid on the other side. Another issue is that if you were to melt a human figure in T-pose made of wax, and you were to melt only the upper arm, it would become soft and behave like a hinge, effectively rotating the lower arm. That seems very tricky too.

The flubber effect you are describing sounds very much like elasticity or springs. I have not tried that yet with flip fluids. Probably a mixture of goals and pointclouds, the overshoot is part of that dynamic motion though. That is how you get that wobble. Perhaps it is possible to add springs to the particles in a custom flip solver... good stuff to dive in and learn more.

Edited March 22, 2011 by pclaes

[pclaes]

That's why I said that this could be even easier to do using cloth or softbodies , that might work

With changing pointcounts coming from an emitter?

Perhaps if you can add and break springs on the fly.

Makes me wonder how I would represent that, perhaps resetting the rest lengths of the springs every n frames.

[varomix]

With changing pointcounts coming from an emitter?

Perhaps if you can add and break springs on the fly.

Makes me wonder how I would represent that, perhaps resetting the rest lengths of the springs every n frames.

I was thinking of just dropping a cloth object over the twinkie

[Nerox]

The pleasure is all mine, finally some tech stuff I can contribute to ;-)

Is that true? Especially the "springs" part sounds more like elasticity. In SPH fluids they can break and you get that nice shockwave propagation (like in the Houdini demoreel a few years ago where the piece of dough gets cut by the knife.)

So what is viscosity then?

According to wikipedia ( http://en.wikipedia.org/wiki/Viscosity ):

From that definition I do not get the impression there are much springs involved. I do agree with the inter particle forces though.

You'e totally right, I should have been more clear about this. I shouldn't have used the word springs, I meant particle to particle forces that can break. It would be totally awesome if, Lagoa doesn't do this, those particle to particle forces could rebind to new neighbours. Like viscose fluids merge together again in real life.

Alright, so let's not multiply the veloctiy. How do we extract "the fluid velocity" from the "gravity velocity"... generally a velocity is built up from a combination of forces added together. So perhaps we could subtract the gravity, add some interparticle and per particle forces, and add the gravity back on. How would that work with collisions...?

That is a good question, I've attempted to do this but I didn't succeed. I guess there was a reason why it didn't work, or I as a TD (who can't touch code), could do it.

I think this is where the solution lies. I have some experience with flocking system and fuzzy logic. I think adjusting the force based on the distance between the particles tends to get rid of this jitter, especially when combined with (non-linear)ramps. It will always move a bit as it is always trying to find an equilibrium between push and pull. This is the difference between a solid and a fluid, no? The particles in a real fluid in the real world are moving too, in a solid they are fixed.

This is already possible. In the same way you use a sopsolver in the post solve to reduce the velocity to 0, you can add to the velocity based on a pointcloud lookup to push and pull points.

The problem with the pointcloud approach is that if you were to put a metal plate in between, it would ignore it and try to attract towards the fluid on the other side. Another issue is that if you were to melt a human figure in T-pose made of wax, and you were to melt only the upper arm, it would become soft and behave like a hinge, effectively rotating the lower arm. That seems very tricky too.

I guess you got a point here, how ever, I assume you would like to do this after the volume solve and when the velocity is projected back on to the particles. But what about the non-divergence of the fluid? Since this is handled in during the volume solve. Non-divergence seems to be the tricky part in all this.

I've attempted to create my own particle separator (particle separation is handled prior to the volume solve), since I, arrogant as I'm, figured that I could do a better job then Jeff (Senior Developer at SESI, he created DOP's) . Obviously I failed since in the end I was reinventing his particle separator ;-). The tricky thing with particle separation or compression / non-divergence on a particle level, is that particle separation as it exist right now only separates the particles in 1 plane. I don't know how to explain it in a better way than that you can only move away or in the opposite from your closest points. This sounds like a good idea, but often it isn't the best direction and iterating over a lot of points get's very slow so you don't want to do that either.

I think that the technology that's used on cloth might be an interesting field. Michiel (Developer on Cloth) tried to explain me how the cloth solver works. Since it's based on polygons, edges ánd points, and it's al about shear, damping and stretch it might be relevant for fluids. To simulate cloth you can have easily millions of possible collisions, to get around having to process them all you can, in a clever way, 'guess' in which area's it's most likely to collide for the current point. Maybe to make your solution work, we could try to do some business in the 'guessing' area. Don't know if this makes any sense, but these are just my two cents.

The flubber effect you are describing sounds very much like elasticity or springs. I have not tried that yet with flip fluids. Probably a mixture of goals and pointclouds, the overshoot is part of that dynamic motion though. That is how you get that wobble. Perhaps it is possible to add springs to the particles in a custom flip solver... good stuff to dive in and learn more.

Flubber is quit an extreme, but I would like to do some jello type of fluid. I wouldn't say that it's that much elastic, maybe a little bit. I was more thinking of a damped 'spring' force, one that is allowed stretch but due to the damping won't come back.

Do you think that having particle goals would work for fluids? I can see how that would work for a squishy object, but a fluid? If I would attempt to create a force like this I would like to have a big range, ideally from water to solid (Guess that isn't going to work, but let's say half way then ;-) )

[Macha]

I shouldn't have used the word springs, I meant particle to particle forces that can break. It would be totally awesome if, Lagoa doesn't do this, those particle to particle forces could rebind to new neighbours.

I posted a link to my melt solver experiment video a while a go. It does exactly that. I should really dig out this file again, it's buried in a backup drive of an old computer.

Part of it is here. Maybe somebody wants to have a look at it. I can't remember what most of it does anymore.

Edited March 23, 2011 by Macha

[bunker]

That guy posted something on Odforce a while ago if I remember correctly :

http://lulu1315.wordpress.com/2009/05/22/simulating-with-voxels/

pretty cool

[Macha]

Cool link bunker! Did he do something like this then?

Edit: vectors are only changed for easy previewing of advection

meltingpot.hip

Edited March 24, 2011 by Macha

[~nature~]

I wonder if it is possible to do the simulation, viscosity in POPs but at the end of each timestep, make the particles divergence free in DOPs.Maybe import the velocity in DOPs and finally back to advect the particles in POPs. so the POPs can do some liquid like stuff without losing some flexibility ?

[Macha]

I wonder if it is possible to do the simulation, viscosity in POPs but at the end of each timestep,

Yes it is, I am preparing a video of it now. I think I got a reasonably good result.

I actually think it is also possible to do convincing bits falling from a melting object. I'm not sure I can do that yet but it may be a matter of masking/scaling forces. There is also a useful gas elasticity node but I can't get it to work properly because it always asks for missing attributes and I'm not sure where they come from (hand made or supplied by another node, the docs are not clear on it).

It is also possible to fake a solution to the problem of "hanging" geometry by continuously emitting from the object you melt and advecting it by its own smoke sim as it were.

Edited March 24, 2011 by Macha