ThreeBody 2.0

Infinite Force? Forty year old FORTRAN to the rescue!

I continue to be fascinated by the complexity that comes from the simple problem of three masses interacting through gravity. Last year I released the ThreeBody app to demonstrate some of this complexity – challenging users to place three bodies so they would stay together. For bodies at rest this is probably impossible (although I am not aware of a proof).  An early commenter asked exactly the right question: “Is the ejection of a body physical or an artifact of the simulation?”.

In the case of my app, in most cases it was an artifact of the simulation. I have been on a journey to remove this artifact and better demonstrate that it is STILL very hard to find solutions that stay together and this is now purely because of the physics and not the implementation.

The result is a significant reboot of ThreeBody, one that allows velocities to be added to the bodies and as a bonus has a gallery of very cool known stable three body solutions.

Close Encounters Have Near-Infinite Force

The force of gravity scales as 1/r^2. Start with two bodes at rest a fixed distance apart, attracted by gravity. As they get close, r (the distance between them), gets small and 1/r^2 becomes HUGE. In a game simulation applying a huge force for a short time step can result in an object moving a large distance, often far beyond the other object. In reality the pair would get the same very big force restraining them as they move past the closest approach. If you think about energy conservation and ignore the collision – it is impossible for the two bodies to fly apart. They can only get as far apart as they started (assuming they started at rest). If two bodies interacting do fly apart – it is an artifact of the simulation not coping well with the very large forces at close approach.

Simulation artifacts have been a well known issue in gravitational simulations since the beginning of computer astronomy experiments in the 1960s. There are ways to transform (“regularize”) the co-ordinates and the forces so that the infinities do not arise during close encounters. This is commonly done in scientific-grade simulations but in game physics is not typically demanded (since the collision usually results in some form of destruction).

Since my app was trying to model these close encounters, it needed a higher pedigree solution.

As usual, I started by buying more physics books and downloading papers. This convinced me that I did need to have a regularizing algorithm and also showed me that doing one from scratch would take some time. Since there is no substitute for running code, my next step was to look and see what researchers were using and if I could adapt it. There are some fantastic programs available (see references below) although many are instrumented for research, scaled for many masses and do not not need to be concerned about real-time performance. These programs are BIG and generally written in FORTRAN or C and I was hoping to continue to use C# within Unity.

I finally found the code TRIPLE from Aarseth and Zare developed in FORTRAN in 1974. It was about one thousand lines. After several attempts using tools to do Fortran to C to C# and experiments building the code as a C library and calling from Unity, I decided that the simplest approach was just to transcribe the code by hand. As an added bonus I would gain a much deeper insight into how the algorithm worked. The code then needed a bit of re-arranging to meet the real-time needs of evolution during a graphical application, and changes in reference frame (since the algorithm operates in the center of mass frame).

ThreeBody now uses the TRIPLE engine and the encounters continue to be very fascinating – even more than before. For masses with no initial velocity it is still difficult to find long lived solutions. The full version of ThreeBody allows the bodies to be given initial velocities allowing even more solutions to be explored. The full version also allows a choice of integration engine; you can go back to Leapfrog to see just how different the results are and monitor the change in total energy – which indicates the error in integration. There is also a higher pedigree non-regularized Hermite integrator for comparison to Leapfrog.

A large gallery of very cool three body solutions is now part of the app. Ranging from solutions found by Euler and Lagrange in the 1770s to those found as recently as 2013. These are hypnotically beautiful – even though not all of them a stable.

For those who want to delve further an annotated reference section is provided.

Resources and References

Three Body Solutions:

Broucke (1975) On Relative Periodic Solutions of the Planar Three Body Problem, Cel.Mech, 12, p439 SAO/NASA

Henon (1974) Families of periodic orbits in the three-body problem, Celestial Mechanics, vol. 10, Nov. 1974, p. 375-388. SAO/NASA

Suvakov (2013) Numerical Search for Periodic Solutions in the Vicinity of the Figure-Eight Orbit: Slaloming around Singularities on the Shape Sphere arxiv

Suvakov and Dmitrasinovic (2013) Three Classes of Newtonian Three-Body Planar Periodic Orbits arxiv


Aarseth, Zare (1972) A regularization of the three-body problem. Celestial Mechanics, vol. 10, Oct. 1974, p. 185-205. SAO/NASA

The discussion in The Basics of Regularization Theory by Celletti provides a very accessible introduction. More discussion can be found in Heggie & Hut, and Aarseth.


Aarseth (2009) Gravitational N-Body Problems, Cambridge Univ. Press. (Very comprehensive, detailed discussion of algorithms.)

Heggie, Hut (2003) The Gravitational Million-Body Problem, Cambridge Univ. Press. (A readable, wider ranging overview of N-body simulations and the behaviour of star clusters)

Roy (2004) Orbital Motion, CRC Press (Derives Euler and Lagrange three body solutions. One of the classic texts of orbital mechanics.)


The “defacto standard” code is from Aarseth. This is all in FORTRAN. The TRIPLE integrator used in ThreeBody is derived from the TRIPLE code here.

Starlab is another widely used collection of programs.  The Hermite integrator offered as an option in ThreeBody is a modified version of an integrator in Starlab.

17 thoughts on “ThreeBody 2.0

  1. Elle

    Houston: We have a problem. If one of the bodies is the earth, and the other is the moon, and the third body is an asteroid, that the moon attempts to capture, and fails, sending it on a short trip to the first body, the ‘classic three body problem’ becomes an ELE. Extinction Level Event.

  2. Shannon Spires

    Very cool app Peter. I was a graduate assistant to Roger Broucke many years ago and wrote many simulations for him. From him I learned more about numerical integration that most people will ever know. It’s an amazing field, and he was an amazing teacher.

    1. Post author

      That’s cool. Now that I have become interested in these problems I wish I had paid more (any) attention in my numerical methods classes. I’ve been learning as I go – but I had no idea the field was this vast!

    1. Post author

      The easiest way for me to write games for iOS and Android (and have an awesome toolkit of support code) is to use the Unity game engine. This allows scripting in C# or javascript.

      Android and iOS do allow you to put in your own C/C++ code, but the way this is done on each platform is slightly different and is a bit annoying to maintain.

      Hence the by-hand translation.

    1. Post author

      Yes – like many upper-year/grad texts they have a small audience and a high price. In some cases I found used copies online. Cheaper, but still not cheap. I recently got “N-Body, The Cambridge Lectures” from a bookseller in Delhi. Arrived on my doorstep in Ottawa four days later. Crazy!

      Sometimes you can find online stuff. “Moving Stars Around” is a good intro and free online.

          1. Bob

            Ok, good to know!

            Sverre has errata on his website for that book, although it looks like it’s for the 2003 edition.

            Also, I was able to find free PDFs of those books online! Gonna give them a read. If they helped you, I would surely have a lot to learn from them too.

  3. Steve Robbins

    Wow, what a great Christmas present! I love the upgraded graphics! And the library of canned solutions.

    I have another question, though. When two stars come close to each other, they seem to slow down — it actually seems like the whole simulation is running more slowly or with smaller time steps. However, the counter in the top-right corner — which I assumed was a clock — seems to keep ticking at a constant rate. If that counter is indeed displaying simulation time, then the bodies’ speeds drop as they get close together, which doesn’t seem right. Is my intuition wrong? Or is that counter displaying something else?

    1. Post author

      Thanks Steve.

      Good point about the timer. That’s a bug. It should be based on physics time, not wall time. I’ll fix that up in a few days.
      (The new integrator is a variable time integrator and my code tries to smooth it out, but the bias is for accuracy.)

    1. Post author

      Thanks. There is more coming:

      – fix time so that physics time is displayed and runs more in real-time
      – slow/med/fast
      – gallery to name and save your favorite creations
      (This is done, just need to produce and push)

      Longer Term:
      – explore the Euler (2 fixed masses) and Lagrange (one pair in a fixed orbit) solutions. I have a book dedicated to each in my input pile.

  4. legalsounds

    My brother recommended I may like this web site. He was once entirely right.

    This submit truly made my day. You can not consider simply how much time I had spent for this info!


Leave a Reply

Your email address will not be published. Required fields are marked *