I have been trying to figure out how to make an object fall, then splash upon contact, and I have hit a roadblock.
The way I had thought of making it work, is to animate the fall, then start the simulation on the frame before impact. However, I don’t know how to tell the fluid simulation to inherit the animated velocity.
Does anyone have an idea on how this can be pulled off?
Well that’s just one of the beauties of Blender - you don’t have to tell the fluid anything about the velocity; the fluid sim looks at the position of the obstacle (the object that’ll be falling over) from frame to frame, and in combination with the RealWorld size variable, is able to calculate how fast the object is moving and what effect it will have on the fluid.
I’ve just got something baking while I type, that seriously took about 3-4 minutes to setup!! what I did was:
()make a domino and set it to about 15 degrees from vertical.
()I then created a largeish box that would function both as the fluid’s domain and as the surface that the domino would fall over onto.
()After doing this, I set the domino to be a dynamic rigid body and set it’s collision radius to 0.1
()Told the game engine to record to IPOs and hit “p” to simulate the fall.
() Added a cube slighlty smaller than the domain and scaled it’s height so it was like a thin layer of water on the bottom of the box that is the domain
() set the domino to be a fluid obstacle (free slip)
() set the large box to be a domain (also free slip)
() set the thin box to be my water as a fluid
() set the real-world size to be about 25cm (0.25)
() set the end-time of the fluid sim to be 0.3 (even though it takes about 70 frames for the domino to really start hitting the fluid)
() set the resolution to 100 & hit bake.
() Also added a plane so that the liquid wouldn’t look like it was floating in space - this plane doesn’t interact in the dynamics or the fluid sim in any way at all.
It should be just about done by now, I’ll see if I can’t render out an image from the sequence. Ah-hah! Here’s frames 59 and 77 of the animation. A little more tweaking could be done perhaps, but anyway, it’s proof of concept.
PM me if you’d like me to email you the .blend file.
Simon
Thanks for that outline, but I think I didn’t explain myself clearly. What I’m trying to do is turn the block into a liquid right before it hits the ground, so that it splatters over the ground, similar to a water balloon, but it is absolutely rigid until right before ground contact. Does that make sense?
So until ground contact, there isn’t anything except for the ground plane and the falling block, and upon impact with the ground plane, the block liquefies and splatters over the ground plane, so that there is nothing but the splattered liquid remains on top of the ground plane.
I think you need both objects - one liquid, one solid - and need to switch the layer (i.e. visibility) while animating.
That’s a good idea, putting them on two different layers. How then can I record the block velocity on layer 1 and give it to the liquid block’s velocity on layer 2? That is the issue as far as I can tell, how to communicate to the liquid block the velocity from the falling block, so that the fluid solver correctly splatters the liquid block across the ground plane.
smacks head:
Oh, of course! Now I gotcha.
That’s what I was thinking, just key the layer that the solid object and the liquid objects are on. Animate the falling solid object, change and key it’s layer at the right moment & key the fluid to then be on the visible layer.
So, I gave it a shot. The solid part worked just fine. I then set the starting frame to the first frame I wanted to see the liquid on then gave it some initial velocity and hit bake - only problem is that the baking totally ignored the starting frame in the animation settings.
So, I rendered the falling solid object out to uncompressed frames then rendered the splashing fluid object out to uncompressed frames. It’s now just a matter of loading the two sets of frames into the Sequence Editor and joining them both into a single sequence.
Should’ve known I was missing something!:spin:
Now this is a far more interesting idea. Nice one, I’m really having some fun getting this to work, cheers!
S.
Yeah, it sounds so simple in my head, but I haven’t been able to make any headway. Is there a way to record the velocity of a given object at a given frame, and then give that to the fluid object as its initial velocity?
Well, I got it to work - though I was a little hasty and too lazy to calculate the velocity of the domino correctly and give that to the fluid, but bear with me - it’s not really that hard…
You’re going to hate this answer, but short of writing some python (which would take me longer anyway) you’re going to have to do some pen and paper calculations.
What I would do is measure the location of one of the vertices on the top of the domino (one of the two that hits the ground going the fastest) at both the frame before impact and the frame of impact. I’d do this by selecting it, snapping the 3d cursor to it then opening up the View->ViewProperties dialog - this will give you the position of the 3d cursor.
Then, I’d work out how far forwards it moved and how far downwards it moved, I’d write these two numbers down. Next, I’d look at the largest side of the domain and look at what I had the RealWorld units set to, I’d also write these two numbers down.
I’d then calculate how many meters/unit this works out to & write that down.:spin:
Then, I’d take this last number and multiply it by the number of units the vertex travelled in one frame. I now know how many meters per frame the object is moving when it hits the ground. Multiply that by 24fps and I have the number of meters per second it’s travelling at the time of impact. :whew!:
I just tried that, but it was all out of whack, muuuch too slow - then it dawned on me that the game engine is treating each unit as a meter when it does it’s calculations. Hmmm, so then I multiplied these numbers by the inverse of the domain RealWorld size (1/0.03 = 33) This seems to give quite a pleasing result, though to be honest, like much of the work one may do with fluids, I think (EDIT: I’m SURE) it may well be easier to go with some values that just look good.
But anyway, here’s all my figures in a worked example:
Frame 69:
VertexX = -2.37
VertexZ = 0.12
Frame 70:
VertexX = -2.39
VertexZ = -0.04
Travelled in 1 Frame:
X = -0.02 units
Z = -0.16 units
Domain
RealWorld Size: 0.03
Blender Units: 11.5
Meters/Unit: 0.03 / 11.5 = 0.0026 meters/unit
Velocity (meters/frame)
X = 0.02 * -0.0026 = -0.00005217 meters/frame
Z = 0.16 * -0.0026 = -0.000417 meters/frame
Velocity (meters/Second - uncorrected)
X = 24(fps) * -0.00005217 = -0.00012 m/s
Z = 24(fps) * -0.000417 = -0.010008 m/s
Velocity (meters/Second - corrected)
X = (1/0.03) * -0.00012 = -0.04 m/s
Z = (1/0.03) * -0.010008 = -0.33 m/s
:eek: Man, that’s way too much in the way of maths to be doing at 5:40am, but it does as I say, seem to give pleasing results. To be honest, I think it’d just be quicker and easier to take a guess at the initial velocity, bake at a resolution of about 50, render at 200*150 and insert into the sequence editor, SAVE the sequence editor file. Give it a try, and if it doesn’t work out, reopen the simulation file, tweak the values, re-render the fluid part, SAVE, then reopen the sequence file and re-render the sequence. Once a pleasing speed has been reached, go back and re-bake and re-render everything at a more suitable resolution.
Jebus! Did I really write that much??
Hmm, told you you weren’t going to like my answer…
Time for some breakfast methinks… enjoy!!
Wow!
You totally went above and beyond. Thanks!
