3D graphics in your browser tend to want to use all the processing power available on your device. A typical metric people look at is frames per second or "fps". The benchmark is keeping your script running at 60 fps.
The script I am currently working on - c19-viz3d - is generally running at between 30 to 40 fps. There is a large variance, however, that depends on whether you are viewing it on an old phone or the latest gaming computer. In any case it would be a really nice thing if we can get it back up to 60 fps.
I spent a lot of today on a cookbook example that explores helping three.js web pages run faster miles an hour. As and when success is achieved, the code will be folded into the main app.
The code I ended up with is running below. Click the buttons to check out the three different modules. At top left of the menu, you can click "load stats.js" to the fps for the module currently running.
The interesting thing about all this actually has little to do about the code itself. It has much more to do about how the code in today's example was written
Pair Programming
Since March 30 Harold Reingruber have been pair programming twice a week for a couple of hours each session.
We met up this morning on Google Hangouts. I mentioned the effort I had put in over the weekend - for details see my post of yesterday 2020-04-26 dev.to, glitch, markdown & three.js. I pointed out that the speed-up was very good but that there were a number of issues with scaling objects and setting their rotation. These issues would be difficult to overcome. Therefore we could could move on to new topics.
Nonetheless Harald wanted to double click into the issues. We spent much of the two hours hacking code and not really solving anything. At the end of the session we were just about where we started. BUT! But somehow during the session Harald set things up in such a way that the scaling of objects appeared to be working as we hoped they would work. But apart from that brief instant where things looked right we had nothing really. And, as we all know, you cannot un-see something.
I had seen the scaling work. There were no doubts. Within two hours I had the module totally working as desired - and in just nine lines of code.
Frankly, the experience was like magic. I came in a negative Ned. Then just a few hours later I became positive Pete
I am still not entirely convinced that pair programming is "good" use of time. Then again, if "magic" happens - who cares?
Nice example
A cookbook example is code that you and others can fork again and again. The example tends to sit a folder somewhere along with many other examples. From time time you visit that folder and click on all the examples to see if one might be doing something you could use just now. It really helps you - and others - if the cookbook example shows more than boxes jumping up and down. So here is the cookbook example that was started over the weekend and is now running at 60 fps. Move your cursor over any of the "bars" to see the population of the city and more.
Thank you SimpleMaps for the free, open source data.
Top comments (0)