Splitting linear and angular into 2 separate aspects. Allows rotating entities without position (e.g. for entities where position is done with nbody physics)
Creating a new combined aspect, that just delegates all work to the other two
Modifying angular integrator to use jobs if there are enough entities
Updating job queries to accept not being given a query object
Added editor for query job completion gate
Added support for open generics in system editor attribute
Made integration of linear and angular velocity parallel with each other (only when there are enough entities to justify the overhead of a job)
Also burst compiled inner loop
Creating a new scene for missiles with nbody physics
Optimising SetWorldPositionFromSurfaceCoordinate system
Caching planet data, skipping a entity structure checks
No longer calculating planet orbital velocity (not needed), just position
Adding validation to burn scheduler, so it can't use more mass than what's actually available!
Investigating adding a different way to handle end-of-rail errors
Currently, working with nbodies is tricky due to the risk of invalidating the rail and causing end-of-rail sampling errors (which appear as jittery movement). Could I just switch to live integration of the body when sampling off the end, then fixup any drift (shouldn't be much) when the rail becomes valid again?
Two possibilities:
Live integrate everything, apply error correction to constantly pull back towards rail
Rail sample everything, live integrate only things that can't be sampled
Testing BulletChainSolarSystem scene some more (large scale)
Old interpolation system:
120 bullet entities => 250us
Scales roughly linearly, main thread
New live integration:
600 ship entities => 200us
1050 ship entities => 250us
Scale is almost flat, work is done in jobs
Fixed query error in interpolation system (properly excluding live nbody entities from rail interpolation)
Handling engine burns which exceed allowable fuel usage
Burns are scheduled in advance, using some amount of fuel. Even if fuel usage is validated at that point then later changes (e.g. damage causing a fuel leak) could invalidate those checks, leading to phantom fuel usage (including possible negative mass, if sufficient phantom fuel is used).
Solutions:
Add a system to cancel at the point where mass goes negative?
In the integrator, don't allow negative mass
Pass in wet+dry mass for more accurate checks
Changes:
Ensuring current total mass (dry+wet) does not go negative
Modifying acceleration query to handle fuel changes
Substepping to the exact point in time when mass is exhausted
Passing in masses separately
DryMass (constant)
WetMass (along with timestamp of when this mass measurement was taken)
Significant divergence when doing burns (at high time speed?)
Maybe caused by max steps on live integration
Increased default max steps, stops the lagged movement at high time speed, but doesn't fix drift
At high time speed engine burn fuel usage may be wrong?
Removing burns with negative duration!
Consider tracking the rail over time and slowly pulling live integration towards it
Options
Sample occasionally, store error and fix it over the sampling period
Sample only at the exact rail points, that way there's little/no interpolation