Search Unity

[Released] Gravity Engine

Discussion in 'Assets and Asset Store' started by PeterMu, May 24, 2016.

  1. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    -

    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
     
    Hikiko66 likes this.
  2. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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
     
  3. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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?
     
  4. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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
     
  5. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
  6. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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.
     
  7. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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...)
     
  8. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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.
     
  9. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    Is there a way to use the XZ plane by default rather than XY?
     
  10. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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?
     
  11. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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.
     
  12. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  13. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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 :)
     
  14. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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?
     
  15. Lechuza

    Lechuza

    Joined:
    Oct 3, 2014
    Posts:
    19
    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!
     
  16. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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
     
  17. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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
     
  18. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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.
     
  19. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  20. Lechuza

    Lechuza

    Joined:
    Oct 3, 2014
    Posts:
    19
    Looking forward to it! I also use Chronos for the same reason. Thank you for the fast reply too!
     
  21. Metatronic

    Metatronic

    Joined:
    Jan 25, 2015
    Posts:
    14
    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....
     
  22. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  23. yamlCase

    yamlCase

    Joined:
    Apr 13, 2017
    Posts:
    34
    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.
     
  24. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  25. Lechuza

    Lechuza

    Joined:
    Oct 3, 2014
    Posts:
    19
    Any news on transfer orbits (Hohmann/Bi-elliptical)? Would love to have this feature implemented in GE! Thanks!
     
  26. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  27. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    Does it work with 2017.x?
     
  28. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  29. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    Version 1.5 has been released.

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

    lelad

    Joined:
    Jun 27, 2017
    Posts:
    2
    Hello mate, just wondering if your n-body integrator is time reverse able and has a variable time step?
     
  31. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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/
     
  32. lelad

    lelad

    Joined:
    Jun 27, 2017
    Posts:
    2
    Cheers mate.

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

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  34. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    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?
     
    Last edited: Apr 10, 2018
  35. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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).
     
  36. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    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?
     
  37. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
  38. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    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!
     
  39. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  40. SONB

    SONB

    Joined:
    Jul 24, 2009
    Posts:
    88
    Hey @PeterMu. Any plans for multiplayer support?
     
  41. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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).
     
  42. Kras

    Kras

    Joined:
    Apr 30, 2015
    Posts:
    1
    Is this asset still developed? I consider buying it soon if its not abandoned.
     
  43. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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
     
    Kras likes this.
  44. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    Have you fixed the internal use of floats yet?
     
  45. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    Absolutely buy it. The developer is awesome and provides excellent support!!
     
  46. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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".
     
    vitaliyzaverchuk likes this.
  47. Innovine

    Innovine

    Joined:
    Aug 6, 2017
    Posts:
    278
    This asset just gets better and better :)
     
  48. wightwhale

    wightwhale

    Joined:
    Jul 28, 2011
    Posts:
    390
    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.
     
  49. PeterMu

    PeterMu

    Joined:
    Oct 1, 2014
    Posts:
    43
    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.
     
  50. jwvanderbeck

    jwvanderbeck

    Joined:
    Dec 4, 2014
    Posts:
    601
    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.