After perhaps a month or two of incubation, a proper project website has emerged for the tectonics.js simulator. Updates will be posted to this website from time to time documenting progress on the model in addition to the accounts of technologies, problems, and solutions encountered in the project’s development.
This project comes as the successor to an earlier plate tectonics simulator, PyTectonics. Like Tectonics.js, this project set out to create a 3d tectonics simulator. Unlike Tectonics.js, it did so using the Python programming language, and as such the projects have differing ideals concerning readability and audience. Taking the Pythonic approach, PyTectonics set out to err on the side of readability at the expense of performance. Given the nature of its subject matter and emphasis on readability, the simulation was largely targeted towards likeminded developers.
Tectonics.js is the culmination of lessons learned over the course of developing the earlier pyTectonics program. Chief among these lessons I believe was learning the need for a wider audience in a project of this nature, and in turn the need for technologies that minimize the knowledge required from the user. The niche for a simulator such as tectonics.js is admitantly small and often those who are interested in the project are not necessarily those capable of participating in its development. A person doesn’t need to know how a model works in order to appreciate its output or base his work of fiction on it. All he needs is assurance the model will produce results in accordance with what geologists generally think happens in reality.
With web apps this is largely a nonissue. Any user can click a link. Being asked to use a different browser is a much different experience from being asked to install python and a list of libraries. Any libraries you need can be imported with impunity, and I use this advantage with extreme prejudice - already the simulation is working with underscore.js, as well as libraries implementing kd trees, data structures, and random number generators.
This last point leads into a second lesson emphasizing the importance of mature libraries with a large userbase. Without criticizing Python’s 3d libraries, the web is rapidly converging on technologies used for developing 3d applications, most notably the WebGL API and the three.js library that the new project has come to depend on. The large community that surrounds these technologies in turn often reduces the effort required in finding your own solutions to problems.
Another lesson learned concerns efficiency. PyTectonics started under the assumption that a lot changed since the days of SimEarth, the project’s spiritual predecessor. A new simulator could make no compromise on readability and still deliver adequate performance for the user, if only through concentrating on the efficiency of algorithms. This turns out to be only partially true. PyTectonics as it currently stands delivers arguably adequate performance and code remains pythonic. Oftentimes, the most readable solution has turned out to double as the most efficient solution, as well. However, a problem arises when one considers the algorithmic shenanigans going on in order for python to perform adequately. A good example of this is in detecting plate borders so that collision detection can occur efficiently - a single list is created for each plate on initialization and that list is added to or detracted from whenever the plate changes shape. Every individual line of code is fairly readable in the process, but collectively the model is convoluted by a lot of functions that don’t do much of anything besides saving runtime. I’ve come to the conclusion this ultimately hinders understanding. What’s more, the increased mental overhead makes it increasingly difficult to debug and build upon.
The move to pure javascript for the sake of efficiency sounds counterintuitive. It’s not. As it turns out, javascript on some modern web browsers is around five times faster than python. Here’s a figure reproduced from the study:
These tests were conducted on intense matrix operations, something very similar to what pyTectonics and company have to deal with. Even Safari offers speed comparable to python, according to these same tests. Based upon what’s been implemented so far in javascript, I’d have to agree. At the moment, my private development branch has loosely implemented both rifting and collision in javascript. These two operations from my experience in Python have taken up the majority of runtime. The time it takes to complete these operations varies strongly with the number of grid cells simulated by the application. At approximately 6000 grid cells, my python implementation maybe updates once every second. Threading is what prevents this implementation from becoming unresponsive to user input. Compare this to the javascript implementation, running in Chrome on the same machine - I can run around 10,000 grid cells in a simulation and still get a framerate of 20 fps, no threading whatsoever. I haven’t even considered the savings made once threading is taken into consideration, but rest assured that feature will come at some point.
Certain workarounds I mentioned before, such as caching plate borders, have still not been implemented. I really don’t care to do so. On the other hand, I’ve noticed things while re-implementing that could be done to improve performance without adding complexity to the simulation. It helps to have a robust 3d library like three.js to back you up. A good example is when geometries are updated. PyTectonics represents landmass as convex hulls that were partly occluded by the oceans. If crust rose out from the water, you would removed the object and created a new object with geometry reflecting the change. This was done every frame. Switching out objects was the only operation permitted by VPython, but with three.js, I have the option to manipulate individual vertices. Every plate starts out as an icosahedron and I push out vertices based on whether or not they should be above or below the water. I don’t doubt some of the efficiency improvements may have come from this.
There is only one caveat: tectonics.js will have to be run in a modern browser. Internet explorer 6 doesn’t count. Later versions of internet explorer will only work by virtue of complying with W3C standards. If there are any issues with even the most recent version of IE I won’t hesitate to drop support for it.
To see the simulator for yourself, just click here