GE2 vs GE: Key Differences

There are some important conceptual changes in Gravity Engine 2 as compared to the prior Gravity Engine Asset.

The key differences:

  • GE2 separates the code for gravitational evolution from code that handles game objects and their position updates and displays

  • There are no singletons! A scene may contain multiple instances of GSController, GSDisplay and GECore

  • Unity.Mathematics is used for all internal information, especially double3. Vector3d has been removed.

  • all physics computations of orbits assume a right-handled coordinate system with \(i=0\) orbits in the XY plane. The display of this in Unity is controlled by the XZOrbit toggle in the GSDisplay component. When set all display coordinates have Y and Z swapped to give the “usual” visual appearance of orbits (counter-clockwise motion and correct sense of ascending node)

  • the core physics work is done in GEPhysicsCore. This makes use of the Unity.Collections NativeArray. This allows the evolution to be done via the job system or directly

  • interactions with GECore are best done via callbacks when the physics loop is complete. This ensures that you can switch to Job-mode evolution in the future.

  • scaling is divided into world, GE and display. Display scale, position and orientation can be easily controlled.

  • the scale settings in GSController can be computed automatically

  • the target time for a scale orbit in game seconds can be specified

  • display of an object requires a GSDisplayBody component. The same GSBody can be displayed by multiple instances of GSDisplay

  • the API calls in general are the form of BodyAdd instead of AddBody. The later makes it harder to find related methods and using the Noun-Verb form allows easier lookup in the IDE and Doxygen.

  • orbit specification and propagator selection is all in GSBody as part of the initial data. There is no need for something like OrbitUniversal

  • the evolution of “on-rails” bodies can be done as patched conics by using the Patched toggle in GSbody. This replaces the KeplerSequence style of patched conics in GE.

  • orbit prediction is handled differently. Given a body id, a request for orbit elements can made directly to GECore. In cases where the propagator is keeping the COE up-to-date internally this value will be returned and the RV to COE conversion will be skipped. In-scene orbit display is handled by GSDisplayOrbit

The GECore API supports evolution with recording of specific bodies at specified intervals. This allows for stand-alone “what if” scenarios to be evaluated without any display interaction. In GE this was a challenge because the core engine was a singleton.

What GE2 Does not Have (Yet)

There are features in Gravity Engine that are not yet in Gravity Engine 2:

  • porkchop plots

  • planet atmospheric model and re-entry demo

  • three-body regularizing integrator and stable(ish) three body configurations

  • demo scene for free-return trajectories

What about Gravity Engine?

Gravity Engine will live on and I will continue to support it. I realize creating a game takes a long time and jumping to a new gravity engine may not be high on the list of things to do! I will continue to fix bugs and provide support. (As an example of my commitment to packages I have created, I am still supporting GRTensor, a research tool I created in 1995!).