Hi. This is a continuation of the story about elm-physics. You can read the first part here.
The most important thing that happened since the original post, is that the project got a second contributor, Paul, who did a lot of work to add tests and benchmarks, improved the performance and implemented support for spheres!
I focused on improving demos, added simple shadows, the settings menu and most recently—the fps meter. Making it easier to create demos allowed us to identify and fix certain bugs. Like for example a bug when a sphere would circle around the corner, dive inside the box and then jump:
I set up this demo and was able to constantly reproduce the bug. It turned out, we did not continue with collision tests against faces and edges after the first collision with a corner had been detected. A quick solution was to test against faces, edges and corners and find the closest collision point. Paul figured that we could test collisions in the certain order. That really improved the performance, as you can see on this screenshot from the wonderful benchmark:
For the last part, I saved the most interesting finding. I’ve been following Florian’s experiment—a pure Elm implementation of linear-algebra (without any Kernel code to store vectors and matrices as typed JavaScript arrays). The physics engine seems like a perfect case to compare!
So I implemented another pure Elm version of linear-algebra with identical API, that defines vectors and matrices as record types, then ran our existing elm-physics benchmarks and came to the same results as Florian.
I think this happens because browsers can optimize objects that have the same shape and make them really fast, while reading data from an array requires some extra checks, and it is pretty costly to have lots of tiny arrays for Vec3
. This JavaScript benchmark simulates a part of Elm’s WebGL, that packs data for an attribute buffer. It shows that objects are faster!
To conclude this, what if we remove linear-algebra, and use Elm records everywhere including for WebGL?
- we will remove unnecessary coupling from the Elm compiler, that has linear-algebra types hardcoded for glsl shaders
- we won’t have to fix nasty typos in Kernel code, writing Elm is a much better experience
- we will enable alternative linear-algebra implementations with a reacher functionality, like ianmackenzie/elm-geometry or already mentioned elm-webgl-math, to easily integrate with WebGL
- and most importantly, it will make the code run faster!
In the meantime, we keep working on elm-physics. The current hot topics are: using spatial indexing to avoid O(n^2) collisions and adding features like user interactions and events. If you feel like you can contribute something like this, please get in touch! Also if you would like to use it for something, please let us know about the missing features, so that we can have a more clear prioritization.