Physics engine: Improved scaling performance

[davesmith00000]

Casually noodling around with the Physics engine. The main goal is just to make it scale better, but I made try and look at some other problems along the way.

Relates primarily to: #665

[davesmith00000]

I've started improving the QuadTree implementation so that I can use it here... I've done some stuff already but here is the TODO list:

• Get rid of the 'replace' notion during insert
• Get rid of remove element functions. Replaced with removeAt, which scaladocs explaining the limitations of this operation.
• Add remove by search functions.
• Also get rid of fetch element functions, makes no sense.
• Max depth: The maximum number of sub-divisions allowed.
• Min size: The smallest allowed quad size before we give up and group all remaining results here.
• Multple values: Quad's can hold a Batch of values of the given type
• Max values: Quad's can hold a max value before sub-division unless max depth or min size have been hit.
• Detect duplicates. If a split results in quads that do not change the outcome, stop and group, to prevent infinite depth due to matching values. On reflection, this became a test to see if the bounds of the new value completely surrounded the quad.
• Can we switch to QuadTree.Leaf syntax? (i.e. enum)
• Move out of extras to Indigo proper
• SpatialOps instance for Circle + tests
• SpatialOps instance for BoundingCircle + tests
• SpatialOps instance for Line + tests Not doing, cannot define a bounding box for an infinite line. 😄
• SpatialOps instance for LineSegment + tests
• Check benchmarks.
• findClosestTo searches the whole tree, as it must. Add a searchAt which only looks in the quads under the vertex specified
• Add Scaladocs
• Remove filter variations

[davesmith00000]

Running some benchmarks. The changes made so far do not appear to have meaningfully affected performance, but the new implementation has many benefits and is more accurate, so I'm calling that a win.

Before

After

[davesmith00000]

With the QuadTree updated, I'm back to looking at the Physics. Quickly adding in the QuadTree as our broad band culling phase has yielded promising results. 1000 circles used to run at about ~25 fps, and now it's up to 60 fps for a while, until the GC (speculation) kicks in and it drops to 45-50 fps. Still, a good improvement for minor code change.

Things TODO:

• Add the QuadTree as a broad phase cull
• Physics options, for tuning the simulation:
  • Think about how to supply QuadTree.InsertOptions, currently I'm making an educated guess. Good enough?
  • Should there be a defined simulation area? If things move forever than the simulation resolution is affected since the QuadTree is covering an ever expanding area. I bet that's why the performance drops actually. If things leave an area are they culled / ignored? Could we use that as the superBounds? (UPDATE: Indeed, this was the source of the performance drop.)
• Solve the bullet through a paper wall problem. Physics: Solve the 'tunnelling' / 'bullet through paper' problem #576
• Consider optimising the collision code. Currently I do many, many loops, some of which are duplicates.
• Consider a mutable solution... does that mean a mutable QuadTree?
• Mark all transient colliders as static

[davesmith00000]

I was going to have a go at the tunnelling problem (#576) here too, but I think I'm going to wrap up this PR now and come back to that in a separate piece of work. There's a lot here already.