12,997,531 members (58,337 online)
Add your own
alternative version

#### Stats

116.1K views
2.9K downloads
173 bookmarked
Posted 21 Jul 2007

# Fun With Gravity

, 28 Jul 2008
 Rate this:
Please Sign up or sign in to vote.
A gravity simulation particle system.

## Introduction

This article is a fine example of what happens when programmers get bored. There's nothing exciting in the code, maybe a gentle introduction to GDI+. It was just a fun project to mess with, and it's addictive to play with. So I thought I might share it.

I was thinking about the fact that every particle in the universe is constantly gravitationally affected by every particle in the universe, and wanted to see what it would look like modeled in software. It's been a number of years since I cracked a Physics book, so I can't guaranty my accuracy with this project... But it sure is pretty.

## The Code

### Calculating Acceleration Due to Gravity

The method I chose for calculating the gravitational effect of each particle `p<sub>n</sub>` on particle `p` is this: I create a vector that extends from one particle to the other by subtracting `p`s location vector from `p<sub>n</sub>`s location.

`Vector unit = p2.Location - p.Location;`

Then, calculate the magnitude of the resulting vector:

```float magnitude = (float)Math.Sqrt(
(unit.X * unit.X)
+ (unit.Y * unit.Y)
+ (unit.Z * unit.Z)
);```

Then, you have what you need to calculate the acceleration.

```float factor = (
GravitationalConstant * (
(p.Mass * p2.Mass) / (magnitude * magnitude * magnitude)
)
) / p.Mass;```

The resulting vector is what's needed to alter your particle's velocity due to the gravity of particle `p<sub>n</sub>`. I originally started with the actual gravitational constant `G = 6.672e-11`, but scaled it larger for simulation's sake, allowing smaller masses to be used.

The full calculation loop looks like this. Notice that for each particle, you calculate the gravitational effect on it by every other particle.

```foreach (Particle p in particles) {
...
if (particles.Count > 1) {
Vector a = new Vector();
foreach (Particle p2 in particles) {
if (object.ReferenceEquals(p, p2)) { continue; }
Vector unit = p2.Location - p.Location;
float magnitude = (float)Math.Sqrt(
(unit.X * unit.X)
+ (unit.Y * unit.Y)
+ (unit.Z * unit.Z));
float factor = (GravitationalConstant * (
(p.Mass * p2.Mass) / (magnitude * magnitude * magnitude)
)) / p.Mass;
unit *= factor;
a += unit;
}
p.Velocity += a;
}
...
}```

### Conservation of Momentum with Inelastic Collisions

My collision detection is primitive. I'm only looking to see if a particle's bounding rectangle intersects with another. The Z axes was an afterthought, and in case the X and Y are intersecting, I look to see if the Z locations are with 5 of each other. I got lazy, what can I say. I wasn't that interested in the Z axes, but wanted to include it in the calculations.

In any event, when two particles collide, I combine their colors and masses. I increase their size slightly. And combine their momentum to find the resulting particle's velocity.

```private Particle Merge(Particle i, Particle j, Graphics g) {
...
Vector v = ((i.Velocity * i.Mass) + (j.Velocity * j.Mass));
v /= i.Mass + j.Mass;
...
}```

## The Demo Application

### Controls

There are menu options to Start, Stop, and Pause the simulation. Pause has a keyboard shortcut of F5, and Start has Ctrl+E (Execute from SQL Query Analyzer :). You must start the simulation before you can add particles, and you can restart at any time to reset everything. Clicking anywhere in the picture box will create a particle at that location. The text boxes to the left under the check boxes determines the properties that the new particle will have. You can set the X, Y, and Z components of its initial velocity, its mass, and its size in pixels.

### Buttons

The three buttons under the text boxes, labeled "B", "M" & "S", set the properties to predefined values for convenience. "B" creates a massive particle, "M" creates a medium, and "S" creates a small. The "Background" button allows you to change the picture box's background color.

### Check Boxes

• Trace: Toggles tracing. Tracing now shows a trail for each particle.
• Collisions: Toggles collision detection.
• Show Vel: Shows the velocity vector in red.
• Vel Box: Shows the velocity vector's bounding box.
• Show Acc: Shows the acceleration vector in the particle's color.
• Acc Box: Shows the acceleration vector's bounding box.

The visual representation of the velocity and acceleration vectors is scaled up quite a bit so that they are visible at the scales I was working with. With more massive examples, the acceleration vector line can be pretty long. I may look at changing it to scale variably based on masses, but probably not.

 Velocity Vector Velocity Box Acceleration Vector Acceleration Box Velocity & Acceleration

### Particle ListView

Finally, the list view at the bottom of the window shows some attributes of the particles. The list view now shows all particles but only when paused. While paused, if you select particles in the list view and hit `DELETE`, it will remove the selected particles.

## Conclusion

I don't think there's much to learn from this project, other than some simple GDI+ usage, and I suppose if you're not familiar with operator overloads, you could find some interesting things in the `Vector` class. It was just a fun project to play with, and it looks pretty cool. If I get bored enough some day, I may see about turning it into a screensaver.

## History

#### 07/24/2008

Based on the suggestions by protix & Zimriel I've updated calculations to more accurately represent orbits. I fixed the non-tracing flickering by drawing to an image and replacing the picturebox's image (poor man's double buffer). And tracing has been redone as well. Originally, I wanted to clear the image with a white color with a low alpha so that previous draws would fade. However, drawing an alpha color to the entire image takes far too long. In the end, I wound up having each particle keep track of a number of previous position, which get redrawn with decreasing alpha values. There may be a better solution, but this works for now.

## License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

## About the Author

 Software Developer (Senior) BoneSoft Software United States
I've been in software development for more than a decade now. Originally with ASP 2.0 and VB6. I worked in Japan for a year doing Java. And have been with C# ever since.

In 2005 I founded BoneSoft Software where I sell a small number of developer tools.
Group type: Organisation (No members)

## Comments and Discussions

 First PrevNext
 My vote of 5 Philip P Liebscher26-May-11 18:58 Philip P Liebscher 26-May-11 18:58
 My vote of 5 alain_dionne29-Mar-11 5:30 alain_dionne 29-Mar-11 5:30
 Thumbs up! Bigdeak10-Jun-10 5:15 Bigdeak 10-Jun-10 5:15
 [Message Removed] immetoz6-Oct-08 7:49 immetoz 6-Oct-08 7:49
 Good Article, But ... Member 477036528-Jul-08 23:36 Member 4770365 28-Jul-08 23:36
 Re: Good Article, But ... canozurdo29-Jul-08 2:23 canozurdo 29-Jul-08 2:23
 Re: Good Article, But ... ``` Xmen ```22-Jan-09 16:25 ``` Xmen ``` 22-Jan-09 16:25
 Fun Timmy Kokke28-Jul-08 20:14 Timmy Kokke 28-Jul-08 20:14
 good david bagaturia20-Jul-08 20:06 david bagaturia 20-Jul-08 20:06
 Nice project fgjsdhgsdhg343242342323422-Aug-07 9:04 fgjsdhgsdhg3432423423234 22-Aug-07 9:04
 Re: Nice project BoneSoft22-Aug-07 12:10 BoneSoft 22-Aug-07 12:10
 Orbits protix26-Jul-07 1:32 protix 26-Jul-07 1:32
 Hi, as I am phisicist by education (however 8 years ago that I've done serious physics stuff, software instead ) the orbits problem caught my curiosity... After some code poking I believe to know the reason for the non elliptical orbits. The first (and most responsible) is the implemented gravitational law: For it to be *our* gravitation law it should read: float factor = (GravitationalConstant * ((p.Mass * p2.Mass) / (magnitude * magnitude * magnitude))) / p.Mass; instead of float factor = (GravitationalConstant * ((p.Mass * p2.Mass) / (magnitude * magnitude))) / p.Mass; because you multiply with the distance vector (called "unit" in the code). So you use just another force in the code which happens to be proportional to 1 / distance instead of 1 / distance ^ 2 as the real world gravitation force. The second (and less haevy in effect) inaccuracy is the point where p.Update() is called to update the particles location. If it is done this way, the location on a particle is updated *before* it is used again on the next loop to calculate the distance. Correctly the locations of all particles should be updated *after* all calculation on a time tick is done. An possibility to do this is to split the foreach (Particle p in particles) { "do everything" } loop in three loops: foreach (Particle p in particles) { "do velocity calculation"; } foreach (Particle p in particles) { p.Update(); } foreach (Particle p in particles) { "do the drawing"; } After theese changes a test with 2 "Big" masses, one with y-velocity = -0.1 somewhere on the left and one with y-velocity = 0.1 on the right will result in neat eliptical orbits. Some improvement would be the explicit usage of physical time steps between two calculations. As it is the use of p.Velocity += a; // a is actually the acceleration as well as (in Update()) this.location += this.velocity; containes an implicit time step = 1 (arbitrary units, or seconds if all other units are SI units). An explicit time step would read: velocity += acceleration * timeStep; and location += velocity * timeStep; Then one can variate the exactness of the simulation by making the time step smaller (more exact) or bigger (less exact). In reality the "time step" is infinitelly small (in Newtonian physics). One can estimate the exactness of the simulation by monitoring the overall energy and overall momentum - both should stay unchanged (energy and momentum conservation). In the simulation they do only for sufficently small time steps. It is funny to observe how energy and momentum is "generated" when two particles get to close to each other (collisions turned off). And finally, when doing simulations with many particles, numerics is an issue, using double instead of float is probably neccessary then. Hope this helps to improve the simulation a bit , Plamen Petrow.
 Re: Orbits BoneSoft26-Jul-07 4:09 BoneSoft 26-Jul-07 4:09
 Re: Orbits protix26-Jul-07 21:45 protix 26-Jul-07 21:45
 Re: Orbits protix26-Jul-07 21:48 protix 26-Jul-07 21:48
 Re: Orbits Zimriel14-Nov-07 19:21 Zimriel 14-Nov-07 19:21
 Great Work!! Neo_Shehpar24-Jul-07 11:35 Neo_Shehpar 24-Jul-07 11:35
 Re: Great Work!! BoneSoft24-Jul-07 16:34 BoneSoft 24-Jul-07 16:34
 Physics from a physicist Kory.Postma24-Jul-07 1:20 Kory.Postma 24-Jul-07 1:20
 Re: Physics from a physicist BoneSoft24-Jul-07 2:18 BoneSoft 24-Jul-07 2:18
 Re: Physics from a physicist BoneSoft24-Jul-07 6:02 BoneSoft 24-Jul-07 6:02
 Suggestion Josh Smith23-Jul-07 8:12 Josh Smith 23-Jul-07 8:12
 Re: Suggestion BoneSoft23-Jul-07 16:50 BoneSoft 23-Jul-07 16:50
 Cool! Jay Gatsby22-Jul-07 21:42 Jay Gatsby 22-Jul-07 21:42
 Gravity Screen Saver Obiwan Jacobi22-Jul-07 19:59 Obiwan Jacobi 22-Jul-07 19:59
 Last Visit: 31-Dec-99 18:00     Last Update: 22-Jun-17 22:56 Refresh 12 Next »

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170622.1 | Last Updated 28 Jul 2008
Article Copyright 2007 by BoneSoft
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid