# Deformation Physics

This topic is 4649 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I've been working on a game, and have been trying to think of a way to implement natural-looking deformation physics in 2 dimensions. For example, if there are two globes of water (made up of a series of vertices connected with lines) side by side and they press up against each other, what's a good way to make them squish together and eventually fuse?

##### Share on other sites
This is what I had in mind if, say, a droplet of water hit a wall:

A little bit like the physics used in the game Gish, if anyone's played it.

##### Share on other sites
Not really my area but what you describe sounds a lot like Metaballs. I was sure there was something about it on NeHe but I can't seem to find it.

Hope that helps to get you started.

##### Share on other sites
The only thing about using metaballs is that I actually want the vertices of the object to deform, rather than just looking like they do.

Also, I can't think of an easy way to constrain distance between points. Anyone have any ideas there?

##### Share on other sites
Look into spring-based physics and in particular cloth simulation. You can simulate a 'jelly' like substance pretty well with this.

I don't know what it's like in relation to metaballs, so I may be telling you the same thing. Hopefully it'll help, though.

Cheers,
--Brian

##### Share on other sites
Well, first I'm going to offer my opinion on the idea, and then on its feasability.

You could do it by making a custom class for dealing with your 3D objects; you'll need have the class internally manage the momentum of the object, and the viscosity of the object (whether it's highly viscous like a piece of glass or barely at all like buckyballs or (to a degree) water). The viscosity in this case would be a variable you would set which would limit the motion of each vertex per frame (by just putting an arbitary movement limit on it and saying it cannot move more than this a frame, most likely in a spherical shape [if (object fails to fall within sphere) { project the point onto the sphere using vector projection; }]).

The problem with this kind of thing is that you're doing a LOT of calculations on a LOT of verticies, every frame. Then you have to get into the fluid dynamics of the material; when is the sheering force enough to break a droplet away from a surface, yadda. So, I don't think deformation physics is something you could feasably do right now in realtime, unless you had very, very simple object, which just wouldn't look as good.

Metaballs is a good alternative though.

##### Share on other sites
The number of vertices would be fairly low, say 16-32.

Still think it isn't feasible?

##### Share on other sites
Quote:
 Original post by datalurkurThe number of vertices would be fairly low, say 16-32.Still think it isn't feasible?

Doing some basic mathematics, it really doesn't look good at all. The first goal of an object like this is conservation of volume; since a liquid by definition cannot be compressed, when you move one vertex, all of the others must move to insure that the volume stays the same.

The next problem I see is surface tension; how much pressure does it actually take to deform this liquid glob, which is actually what this whole thing is about. You've gotta determine how much energy is needed to pierce this object and adhere ("Energy of adhesion", the inverse of which would be how much energy is required to break away). Then, you've gotta shoehorn this into verticies.

The two ways of thinking about it would be a) have the verticies define the outer volume of the object, and find out some way to figure out the volume of the inner object (slices maybe?) or b) have a block of either 4 or 8 verticies define a "block" inside of the liquid, in which a group of the 4 or 8 verticies can be transformed, as long as the volume of the remaining solid was equal to the volume you had at the beginning. For a more dynamic model, you could go with 4 (tetrahedrons), but for simpler mathematics, 8 would probably be preferable.

Now that we have that out of the way, you've gotta keep up with the position and force applied to each vertex. If a force is applied to a vertex, you've gotta come up with a way of transfering that force onto other verticies, deforming the object. Giving the whole object momentum would require giving all of the verticies a momentum, or at least faking it inside of your engine by giving the vertex closes to the goal a momentum, and letting it drag the rest of the object behind it (which would look more natural and give you that teardrop shape).

If it doesn't sound like a lot of math, think about all of the difference force vectors you'd have to keep track of and update every single frame, for each and every vertex. While it's a lovely idea, I just think that even with SSE it's going to be too slow to do in realtime.

It'd make a hell of a senior project. I'm probably going to look into this idea a bit more and report back to you what I find out, but I know from Fluids in college that it's not looking very good.

##### Share on other sites
First of all, let me apologize; when I originally read everything over, I could have sworn you wanted to do it in 3D (metaballs are normally a 3-dimensional approach), which adds a HUGE amount of complexity to the equations, and would have been impractical running at realtime.

However, in 2D, you lose a LOT of the complexity, and it'll allow you to make it look better at a lower vertex count.

First, get familiar with Bezier paths, if you're not already familar with them. Next, what I said in my last post is still true; you've gotta maintain the volume (in this case, Area) of the object, because it is a liquid and therefore by definition non-compressible. This is a lot easier to do because finding the area of an arbitary shape is a lot fewer calculations, even though it still does require calculus (and if you're not familiar with Calculus, it might be a bit out of your league, not to put you off anymore than I already have).

Next, you still have two options in implementation; internal triangles or just an outer boundary created with verticies. The second method will require a bit more math, but can be highly parallelized using SIMD instructions available on all modern processors, though for simplicity's sake I'd go for implementation one. Whenever an outer collision takes place, simply change the first polygon accordingly, and then go to the opposite polygon and expand it, which makes up for the difference in size.

The exact equations I don't have right on my hand (it's been a while since Fluids), but you should be able to find them with some googling. I'm sorry I misunderstood you earlier.

Also, moderators: could you move this to Physics? I'm sure the guys over there probably know the equations right off the top of their head for doing this, and I don't have time to do my research right now.

Good Luck!

1. 1
Rutin
33
2. 2
3. 3
4. 4
5. 5

• 13
• 78
• 11
• 10
• 14
• ### Forum Statistics

• Total Topics
632968
• Total Posts
3009587
• ### Who's Online (See full list)

There are no registered users currently online

×