Gravimetrics engine

[SharktasticA]

Due to the complexity of implementing realistic gravity, I have opted to go for simulated interactions for the time being. Actual calculations will be restricted to probes and asteroids.

[ghost]

Sounds good! It will be a lot easier implementing movement and firing scripts with this kind of a system rather than a realistic one.

[SharktasticA]

Indeed. It's quite a bummer since I spend three weeks working on it, but it is for the best right now that we simplify this.

[SharktasticA]

So I now have an idea of how I am going to implement the new system. The new ideal gravity script will have two main methods; GetMovementGravity() and GetStationaryGravity();

GetMovementGravity() will be called every time the object moves, and returns a Vector3 containing the needed adjustments for the movement system to simulate an attraction effect. GetStationaryGravity() will apply an attraction if the movement system is inactive.

@Ajarax , I'd like to discuss how we are going to apply this gravity to your movement system in tomorrow's tutorial. The returned Vector3 should be easy to integrate since you'll just need to add the two forces (the other being player movement Vector3) together. If you're system is too different for that, we should be able to find a way to convert the values to be usable.

Other things I need to iron out is how the script detects if it is in range of a planet. Since instead of calculating the gravity continuously, the script will just calculate a quick attraction vector based on the difference in location when said objects are in a fixed range of each other.

[SharktasticA]

https://github.com/PlaceholderGames/Team1-2017/commit/11cc3f7e3d4346a77328ea911076875d4ca1990f

See this issue for a basic procedure outline of both methods. Aim for basic code completed by the end of tomorrow.

[ghost]

Do you think the new gravimetrics system is stable enough to test movement scripts in? As my movement system is also physics based, combining these two systems shouldn't be hard.

[SharktasticA]

No. Due to other courseworks, I'm a bit behind.

However, if you check master, I have now merged the physics branch into it so you have access to the dummy method GetMovementGravity() which returns a vector3 (which will be raw attraction as explained above a week ago). Whilst I catch up, feel free to experiment on how to access that method from your movement scripts and apply it into the code (which should be into the final processed movement).

The method has some pseudocode inside it so you can understand the procedure of what it does.

[SharktasticA]

I've also set an deadline for my new gravity model as 1st December 2017.

[SharktasticA]

System was completed in time, but due to unforseen issues, this thread will be replaced.

[SharktasticA]

Reopening the issue due to recent improvements of gravimetrics.

Changes since December 2017:

• Added calculation of drag due to atmosphere at the same time as the gravity calculation
• Now encapsulates important gravity data in the GravityProperties class to allow portability of gravity results
• Bodies that should pull the probe get added via an array in designer
• Gravimetrics now applies the gravity directly instead of the movement script, solving the chaotic bug from the demo
• Stationary gravity removed for the meantime

[SharktasticA]

Wiki page for GravityProperties class: https://github.com/PlaceholderGames/Team1-2017/wiki/GravityProperties-class

[SharktasticA]

Updates

• New wiki page for Gravimetrics engine (https://github.com/PlaceholderGames/Team1-2017/wiki/Gravimetrics-engine)
• GravityProperties renamed GravimetricResult
• GravimetricResult wiki page removed and public interface info now stored on the Gravimetrics wiki page
• Drag due to atmosphere calculation transferred to Atmospherics engine

[SharktasticA]

The Gravimetrics is done for now.

[SharktasticA]

Minor update f6b58b8e764d4c3e1c783a3b9176568b6a6da903 Engine gets planets via code rather than being manually entered via array.