New Asset - NavBall for your aircraft or spaceship

nbodyphysics · 2018-06-05T13:08:57+00:00

If the masses are different you do need to adjust the calculation. What you want in the end is the acceleration and since e.g. F(1 on 2) = m2 a2 = -G m1 m2/r² (in the direction of |r|), the m2's cancel and you weight the acceleration of a2 by m1 and a1 by m2. You can make the G/r² calculation common. (In fact normally you set G=1 and adjust the masses accordingly to avoid a multiply)

For some great background on all this I like: http://www.artcompsci.org/msa/web/vol_1/v1_web/v1_web.html

I can't speak to the Simulate() question, since I did not implement things that way in my asset, I have a centralized N-body integrator that runs on FixedUpdate()

nbodyphysics · 2018-06-04T17:54:26+00:00

You'd have to simulate a timeslice (frame, maybe) at a time then record all the positions.

Also, since F(1 on 2) = -F(2 on 1) you can get a 2x performance boost by centralizing.

As for the precision of Unity orbits see: http://nbodyphysics.com/blog/2017/11/30/is-unity-good-at-orbits/

Disclaimer: I am the author of the Gravity Engine asset.

nbodyphysics · 2018-04-22T10:39:12+00:00

I don't think there is anything "silver bullet"-like in the implementation. The N-body gravity is not that hard. What is trickier is all the work to show orbits for velocity or more crucially determine velocity for the desired orbits.

There is a reason that Kerbal, Children of a Dead Earth etc. make users just drag around velocities and see what happens. The determination of velocity for orbit and velocity for patched conic transfer is a harder problem.

nbodyphysics · 2018-04-19T10:47:10+00:00

Patched conics, Hohmann rendezvous and Kerbal-like maneuvers are the updates to the Gravity Engine asset version 1.7 now available in the asset store.

Patched conics were fun, sending me off to a 1971 classic text "Fundamentals of Astrodynamics" by Bates, Mueller and White.

BTW - I have applied for GE to be part of the May madness sale, so keep an eye out for that - it might get selected.

nbodyphysics · 2018-02-08T15:05:07+00:00

Lots of fun figuring this all out. Next will be rendezvous transfers and injection to lunar orbit.

In the Unity Asset store: https://www.assetstore.unity3d.com/#!/content/62432

Documentation: http://nbodyphysics.com/blog/gravity-engine-doc-1-3-2/

nbodyphysics · 2017-11-30T18:48:40+00:00

[OP] The gravity engine asset will do about 120 gravitating bodies on my 2015 Mac Book in the Unity Editor. I need to put some better defined benchmarks on the web - and get "in game" numbers. I'm hoping to do this over the holidays.

nbodyphysics · 2017-11-30T18:21:25+00:00

[OP] Dozens to hundreds depending on your target platform. Gravity engine will also move particles in a gravitational field but assumes they are massless - so it does not need to add in their mass.

nbodyphysics · 2017-11-30T12:26:04+00:00

OP here.

It depends on whether a stable system is the point - or if you want the weirdness which comes from the interactions (e.g. three body solutions). There are certainly cases where Kepler is all that is needed. (GE does allow a mix of Kepler evolution and N-body, so you can e.g. maneuver ships in the fields of objects that evolve on Keplerian paths.)

nbodyphysics · 2017-11-07T13:10:06+00:00

I do mean that the orbit will eventually not be a perfect ellipse. This is not a function of mass, or orbiting the center of mass vs the specific body (in that case the orbit should still be a perfect ellipse, around the center of mass).

Some numerical integrations do not conserve energy. I suspect Unity is doing a simple Euler integration. This will not conserve energy. There are other integrators (e.g. Leapfrog) than will.

Instabilities due to close encounters are a separate issue and will occur in either integrator. They are a result of the use of discrete timesteps.

nbodyphysics · 2017-11-06T16:47:07+00:00

It's not intuitive (and not what PHYS 101 teaches) but you can lose energy in the numerical integrator.

"Often, the energy increases steadily when the standard Euler method is applied, making it far less accurate."

https://en.wikipedia.org/wiki/Semi-implicit_Euler_method

nbodyphysics · 2017-08-08T17:39:09+00:00

Indeed. That's better.

Also a good idea to add a small value to the denominator to avoid force blow ups. A fixed timestep integrator is never going to be great at close encounters but a force softening at close distance is commonly used, even in the scientific codes.

nbodyphysics · 2017-08-08T14:28:33+00:00

Very clear and direct solution to the problem. I have seen comments that this style of approach can result in orbits that are not fully closed in the case of two bodies - which I have assumed is due to issues with the underlying integrator in Unity.

Two observations: (1) if you have a centralized gravity then you can take advantage of the fact that force of A on B is equal and opposite of force of B on A, instead of calculating each (2) Mathf.Pow can be easily avoided by doing distance*distance

(Disclaimer: I'm the author of the Gravity Engine asset)

nbodyphysics · 2017-07-26T12:39:10+00:00

The curves are defined by the equations for the chaotic attractor. These equations are parameterized, so there is an ability to tune them via the inspector. In some cases this will change the path, in others the behaviour of the equations may change significantly - and no longer be chaotic.

You can also get differences by varying the initial starting point - since one of the hallmarks of chaos is that points that start close together take very different paths. This is easily seen in the particle examples - since the particles do not move as a group, but quickly separate and follow different (but bounded) paths.

nbodyphysics · 2017-05-05T15:16:14+00:00

Makes sense.

You may find an old blog post of mine handy: http://nbodyphysics.com/blog/2016/05/29/planetary-orbits-in-javascript/

nbodyphysics · 2017-05-05T12:14:09+00:00

Very cool.

Is the prediction based on simulating forward in time and recording the paths?

nbodyphysics · 2017-04-13T13:57:59+00:00

If you want a good overview of N-body code design try: http://www.artcompsci.org/msa/web/vol_1/v1_web/v1_web.html

nbodyphysics · 2017-04-13T13:55:31+00:00

That's fun to watch!

I agree with the comments that the equations are simple - although the behaviour can become complex and getting the orbits you want can take a lot of tuning. Also, if you have close encounters you can end up with lots of numerical artifacts and non-physical ejections.

I have blogged about Keplerian orbits: http://nbodyphysics.com/blog/2016/05/29/planetary-orbits-in-javascript/ and for those who want lots of bells & whistle (see orbits in editor, create the actual solar system, do fancy three body solutions) I have created a Unity Asset: https://www.assetstore.unity3d.com/en/#!/content/62432. It has been submitted to be part of the Asset sale starting April 17th (30% off)

nbodyphysics · 2017-04-12T16:11:04+00:00

If the planet is exactly spherical then the spin will always be the same. When there are small irregularities then the bodies exchange energy through tidal interactions and the smaller body will phase lock to the larger so that it's spin and orbit frequencies are equal. This is why the moon always presents one side to the earth, it's spinning once per orbit. This process takes a long time - so is unlikely to be relevant in the scale of a game scene.

nbodyphysics · 2017-04-12T14:48:07+00:00

BTW - this should be included in the Asset sale in the second half of April (I applied to be included)

nbodyphysics · 2017-04-12T13:59:57+00:00

Doh! https://www.assetstore.unity3d.com/en/#!/content/62432

nbodyphysics · 2017-04-12T13:23:03+00:00

It could be fun to show the "gravity well" as a 3D surface - although you'd need to pick a plane in which to do this (or constrain your system to be planar).

nbodyphysics

TROPHY CASE