[Released] Gravity Engine

-

Gravity Engine provides a complete toolkit for your space game physics.

- easily add stars, planets and spaceships that interact via gravity
- design orbits by shape and see their paths in the editor
- create rings of orbiting particles that can be disrupted by passing objects
- physically accurate collisions and particle ejection effects
- highly accurate physics, with a choice of algorithm/Kepler evolution
- control of overall evolution speed, scale and CPU use
- huge selection of three body configurations with fascinating orbits

All with no programming or math required.

Extensive video tutorials and documentation.

Developed by a professional programmer with a PhD in astrophysics.

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

 

Hi all,

I would welcome feedback on feature prioritization for the next release.

1) Solar System Support
- select planets/asteroids/comets and set current date/time to get correct position
- control overall distance/timescale
- data comes from a preset list plus the ability to paste in any asteroid/comet from the JPL database

2) Hyperbolic/Parabolic Orbits
- show orbits in scene view

3) Star Clusters
- pre-init with one of several existing star distributions (Plumber model etc.)

4) Hierarchical Integrator
- evolve each body at a timestep scale suitable for it's velocity
- allows larger number of bodies to be simulated for same CPU effort

Thanks in advance,

PM

 

Hi there. I am looking at your asset and trying to determine if it would be suitable for what I am building or not.

Ideally I want an asset that completely removes the need for me to figure out the hard maths of rocket science

I have planets, moons, and satellites - both artificial and natural, and asteroids, as well as AI controlled rockets. Besides the basic need to set up a solar system (not necessarily ours) with proper orbits, but I also need to be able to add/remove bodies and satellites at runtime.

But in addition to those basics, I need to be able to make orbital adjustments for things like transfer orbits. For example, allowing AI rockets to rendezvous with different bodies.

Would this asset do things like calculate Hohmann or Bi-Elliptical transfer orbits for me between two bodies with a shared barycenter? What about impulsive manuevers?

 

The current version will do some (but not all) of the things you list.
- evolve systems in orbit
- add/remove bodies at run-time
- create solar systems (either ours or others)
- allow impulse changes in orbits
- predict orbital path around a dominant gravitational source

The things not supported:
- transfer orbits (Hohmann/Bi-elliptical)

Transfer orbits are "on the Trello board" but I have not done any work towards them and cannot commit to when they will be done.

Hope this helps clarify what Gravity Engine does in it's current release.

Regards,

Peter

 

Detailed demos and on-line manual are now available at:
http://nbodyphysics.com/blog/gravity-engine-doc-1-3/

 

Thank you for the prompt reply. Sadly the transfer orbits are the big item for me right now because the maths to determine that are way outside my skillset It would be an instant buy from me if that got added, but otherwise I think I may as well stick with the simpler Celestial Mechanics toolkit I am using now (though it also is missing those).

I guess I just am going to need to try and figure that part out on my own.

 

Fair enough.

If you decide you need to move between velocity/position and orbital elements then the OrbitPredictor classes in Gravity Engine does have that math implemented. That is a significant part of the math you would need for orbit transfers. (The missing part would be ensuring the arrival time lines up...)

 

So I figure I would give it a try and purchased Gravity Engine this morning. I'll mess around with it and see what I can figure out. Mostly my problem with the math is calculating the required maneuver. IE at what vector, velocity, and time to burn.

I looked at your documentation last night. Maybe I could just use the OrbitPredictor to loop through possible changes until it finds one that results in the proper orbit? Seems horribly inefficient but might work.

 

Is there a way to use the XZ plane by default rather than XY?

 

Do you mean in the OrbitEllipse component?
If you set the inclination to 90 then the orbit will be in XZ.

If you ping me at the support email - I'll get back to you in a day or so with some suggestions about approaches for finding a rendezvous orbit. It starts with finding an orbit with a matching apogee (assume target orbit is bigger) and then correcting to the desired orbit when that apogee is reached - all assuming the orbits have the same inclination. Are your orbits all in the same plane?

 

I kind of meant as a global thing, just use the XZ rather than XY plane. Changing the inclination feels like a hack but maybe that is fine. Just was afraid I might run into issues later on or something.

My game is a top down view game, so all my camera code assumes the game world is on the XZ plane.

 

I think the inclination will be fine if used consistently. You could change the default value in the class - so you don't have to change it as you build scenes if that makes life easier.

The orbital elements (omega, Omega etc.) are all defined according to physics conventions - which tie them to x,y,z in a specific way. Changing the convention would make it confusing for those used to the physics conventions and require a full regression. For those reasons I am not inclined (pun-intended) to modify the core code.

 

In regards to transfers, I will play with it on my own for a bit. I did find some somewhat understandable equations for calculating a Hohmann transfer online.

The thing is that realism isn't actually the first priority which is what kind of kept me away from this asset at first. Propellant isn't a factor at all in the game, and maneuvers can in fact be instant if it works out easier. The only critical factors for gameplay are time and position. By that I mean that I want to be somewhat accurate on how long the trip will take and where the craft are at any given moment.

I have two main use cases:
1) Moving craft under AI control between orbits and between orbital bodies. IE Earth orbit to Lunar orbit, or Earth orbit to Asteroid
2) Moving bodies to other bodies. A key part of early gameplay is redirection of asteroids from their own orbits to put them into new orbits around say a planet or moon.

Anyway I will have a go at this on my own first for a day or two then I might bug you

 

So two questions in regard to handling of time.

1) Changing the Time Scale property in the GravityEngine object doesn't seem to have any effect. I tried a value of 1 and then something ludicrous like 10,000 and my test planet orbited at the same rate as far as I could tell.
2) I want to hook this up to Chronos so I can easily adjust the time factor, so I started digging in and noticed you don't appear to be using deltaTime anywhere. Is there a reason for this?

 

Also having the same problem, time scale does not have any effect.

I would also like to know if planetary transfers are something that you have planned in the future? I bought the asset, and I was wondering where could I start about extending it to support that, its quite out of my skill set and any pointers would be greatly appreciated. Trying to do an exploration game with similar orbital mechanics as KSP. Great work with the engine by the way, the only thing missing that I could think of would be planetary transfers.

Thank you in advance!

 

Hi,
1) The bug
Thanks for reporting this issue. It is a bug in version 1.4 (likely due to all the timescale changes to support different units). Apologies.

I am working on a fix and will push an update once I have it tested.

In general, timescale is not the most efficient method for adjusting the overall speed of a scene. That is better accomplished by adjusting the mass scale. If everything gets more massive then the objects in the scene will move faster, since the forces between them increase. This avoids some of the imprecision that comes from adjusting time step size "on the fly" - which can result in errors in energy conservation in the math engine and ultimately orbits that are the wrong shape.

Timescale is intended to make the integrator do more/less iterations per loop, so using it for big speed up can lead to a lot more calculations and might impact the frame rate.

I'll add a section on real-time scaling to the online manual once I get this fixed.

2) Planetary Transfers
I am interested in doing this feature - several people have asked for it. I am hoping to have some time to spend on it this summer - since I will first need to re-learn some transfer physics. I also want to do it a way that gives choices of "best time" vs "fastest" and allows trade-offs between these.

Regards,

Peter

 

Apologies for the slow response - I did not get a notification. (Please feel free to reach me via nbodyphysics@gmail.com).

1) The timescale update has a bug - I am working on a fix.

2) I am not familiar with Chronos. The engine does not use deltaTime currently. The integrator runs in "physics time" which is some multiple of the elapsed game time. This scaling factor allows the very different system of units. (And this is what timescale should be adjusting - but is not).

Regards,

Peter

 

Chronos (you can see it on the asset store) is a kit for controlling time in your game. Speeding up and slowing down time, as well as rewinding it.

Specifically in my case I was planning to use it to allow the player to speed up time in the game.

 

Ok.

I have changed the code to use deltaTime. I need to re-run some tests and then I can submit the update.

If you'd like a beta copy - please email the support email and we can work that out.

 

Looking forward to it! I also use Chronos for the same reason. Thank you for the fast reply too!

 

This doesn't seem to be an actual n-body simulator, but a kepler orbit path predictor. Before start it simply calculates the orbit. There isn't any interactivity to it at all....

 

Hi,

I'm not sure how you came to that conclusion - perhaps I have not been clear in the write up. This *is* a full NBody simulator with a choice of integration algorithm.

I'm guessing that the ellipses shown in the editor view might be creating the wrong impression.

The orbit ellipses shown in the editor view in NBody mode are a prediction based in two body evolution, but if there is e.g. a third body that influences it the actual evolution, then the NBody code will evolve the objects and the predicted orbit will not be realized. This orbit predictor is useful for getting a rough idea of where a body would go.

There is also a mode to allow Kepler evolution - should that be what you are looking for.

Please let me know if you have other questions.

 

Is Gravity Engine able to simulate spherical gravity at the object's surface scale? i.e. walking around and jumping on the lunar surface. How well will this asset play with another gravity asset such as Circular Gravity Force? thanks.

 

Hi,

Gravity engine is not a great choice for surface gravity. It is intended more for scales on which a 1/R^2 law is used (as opposed to the standard mg force near a planets surface).

I am not familiar with Circular gravity engine. For Gravity Engine to take control of a body it requires an NBody component added, it could control some but not all objects in a scene. It is possible to add/remove a body from GE and then let some other entity e.g. circular gravity control it. Some modest scripting would be necessary to do the add/remove as e.g. the object left the surface and went into orbit.

Thanks for your interest.

 

Any news on transfer orbits (Hohmann/Bi-elliptical)? Would love to have this feature implemented in GE! Thanks!

 

I am planning on doing some work on this after I get version 1.5 released. V15 will support N-body trajectory prediction, showing the paths objects will take in more environments more complex than simple 2-body orbits. There are also a handful of bugs fixed in V15.

One question about transfers. Are you interested in rendezvous (i.e. arriving at the target orbit at a specific time and place) or just transfers from one orbit to another. The former involves "phasing" which adds some complexity.

My current early concept is to create a ManeuverList that holds times and velocity changes, which can then be used by a spacecraft to execute the transfer. Let me know if you had other assumptions about how transfers might work.

Time-wise - V15 is planned to come out in August and then work on transfers will likely start in September. Unclear at this point how much work this will be until I do a bit more reading.

 

Does it work with 2017.x?

 

Yes. I upgraded to 2017.1.0f3 and all the tutorial and demo scenes worked.

No warnings after upgrading.

I do note that the FrameRateTest scene is a bit twitchy - and sometimes stops very early. I need to tune the debouncing of the inter-frame times.

The next release (maybe 2 months out?) will be on the current 2017 release at that time.

 

Version 1.5 has been released.

It features trajectory prediction via N-body look ahead. The tutorial for this is:

 

Hello mate, just wondering if your n-body integrator is time reverse able and has a variable time step?

 

There is choice of integrator for massive bodies in GE. The Leapfrog integrator is time-reversible. The time step can be tuned in several ways, either directly with steps/frame or by changing the mass scale. The time step for an integrator of this type cannot be varied dynamically - otherwise energy conservation is lost.

Currently there is no "reverse time" function. It's not hard to add and has been on my backlog for awhile.

The other integrator is a 4th order Hermite with a dynamic time step that dials up/down based on the fastest velocity in the system.

Aside: I recently blogged about integrators: http://nbodyphysics.com/blog/2017/11/30/is-unity-good-at-orbits/

 

Cheers mate.

Is the Hermite integrator also time reversible? Does it conserve energy? If not, how consistent is it?

 

In principle the Hermite integrator is not strictly reversible or energy conserving. Since it is fourth order (vs 2nd order for Leapfrog) it will still have advantages in energy accuracy in some circumstances - the usual less-than helpful "it depends" that often comes up in numerical methods.

 

How well does this work with a standard RigidBody ? Right now I control my spaceship by adding thruster forces and rotations to its rigid body, and have gravity added as f=GMm/r^2. Will GE see and account for these thrusters on my rigidbody, and adjust the orbit appropriately?
The main issue i see right now is that my orbits are not stable., even in a 2-body situation the orbit is noticably wrong after a short while (i may have a bug somewhere). Is GE the right tool so i can easily stabilize my orbit, and also put some other planets and moons on elliptical rails?

I also use a simple floating origin where I shift things by a few thousand units when the player ship moves away from the origin. Is this likely to mess up GE?

 

The gravity force is done via adding an NBody component which will handle the translational motion due to gravity. You can keep a rigidbody for rotation.

GE moves objects directly and not through AddForce onto RigidBody.

It does allow a mix of objects on rails and under gravitational control on a body by body basis.

The shifting of the internal physics representation to e.g. center a spaceship is not currently supported, but since I have seen that request a couple of times now, I will add it to the content for 1.8. (1.7 is code complete and adds patched conic xfers and Hohmann rendezvous phasing, hope to have that up in two weeks).

 

Thanks for the quick reply! How would I translate my rocket around, if AddForce() won't work? My primary use case here would be docking with another vessel. I'd have the target vessel on rails, and the piloted spaceship under GE control. I'd like to be able to make very small changes to the velocity with thrusters, so I can maneuver around and dock, yet have these thruster effects alter the entire orbit, so I get correct relative motion between the two vehicles as both go around the planet. Will that work? Are there any floating point inaccuracy issues I need to be aware of when doing this?

If I want to do planet surface operations, I am quite ok with disabling GE and implementing my own trivial gravity as I approach the surface, but I assume I can somehow get the orbital velocity from GE and use that with AddForce() once I remove the NBody component, so there is no jerk in the motion?

 

GE has routines to apply impulses to bodies to allow course corrections. These can be called directly or can be queued up for future times via a Maneuver object (see http://nbodyphysics.com/blog/gravit...ers_Trajectory_Intercepts_and_Orbit_Transfers).

AddImpulse: http://nbodyphysics.com/gravityengi...engine.html#aedaeb3c2f986e9aded484fe6091aecfc

If you get close to a planet surface you can just remove it from GE control via RemoveBody().

 

Sounds great! Will purchase as soon as i get home from work
I can wait with the floating origin, just happy to hear it'll be worked on!

 

Excellent.

Feel free to ping me at nbodyphysics@gmail.com for questions or to ask to be added to Beta for 1.8 so you can get early access to origin translation.

 

Hey @PeterMu. Any plans for multiplayer support?

 

Multiplayer support is a cool idea.

There are no near-term plans - since I have a backlog of orbital mechanics features:
- Lambert (ellipse to ellipse) transfers
- lunar free-return trajectory calculation
- lunar trans-Earth-injection computatio

and a desire to get the calculations off the main thread (maybe using the job system).

 

Is this asset still developed? I consider buying it soon if its not abandoned.

 

Hi,

Yes. I have issued one update already in 2019 and have the next one about a month from completion.

Coming in the next release will be:
- a universal orbit (moves smoothly from ellipse to parabola to hyperbola)
- "all on rails" mode to allow jumping time forward and backward
- change path of "on-rails" ships via ApplyImpulse
- support for "on-rails" orbit transfers that use a sequence of conics

I generally update every 3-4 months as new features are added. There is still a lot I want to add to the asset. I expect to be working on it for some time!

P

 

Have you fixed the internal use of floats yet?

 

Absolutely buy it. The developer is awesome and provides excellent support!!

 

The internal NBody physics has alway been in double, although orbits are initialized with floats for the eccentricity etc. Kepler evolution was done in floats.

The next release (mid-April 2019 or so) will include a full double precision universal orbit (ellipse, hyperbola and parabola) that will accept double for the initial conditions and do Kepler evolution in double precision. The Kepler mode will also support ApplyImpulse, so ships can make maneuvers and stay "on-rails".

 

This asset just gets better and better

 

Hi PeterMu,
I'm wondering if there's anything in gravity engine which handles rotations. I.e. putting an object in orbit with an initial rotational force.

 

I assume you mean as in a spaceship spinning while orbiting?

This can be handled by making a child object attached to an NBody (influenced by gravity) and then using a rigidbody on the child and using the usual rigid body techniques to apply rotations. The child will spin as required and the parent will ensure it moves in the correct gravitational path.

 

This may be a silly feature request so please feel free to tell me so, but would it be possible to get a new Units setting that aligns with standard astronomical units for mass IE solar masses? Right now I feel none of the presets really work well and I have to convert everything. Not sure how feasible this is, or even if maybe it might be easier to just make a custom converter for myself. For the game I am working on now I am dealing with units in AU, Solar Masses, Solar Radii, Earth Radii, Jupiter Radii, etc.

Maybe just making my own custom conversion class is the better way to go now that I type all this out.