The collision detection works pretty well for basic objects (ie. cube) at the moment. However, when these objects start to move faster (ie. travel larger distance in small amount of time), a hidden problem becomes more apparent and needs a solution.

The solution to this is ‘stepping’. As briefly explained in a previous blog, the basic idea behind ‘stepping’ is that we take a normal ‘step’ (ie. an update), and break it down into smaller steps. So in the case of a moving object, lets say in one update, it travels from current location to 10 meters ahead. Now what we do instead of checking for a collision at the current location and at the 10 meter mark, is break this 10 meter into smaller steps and check for collision at each of them. So lets say we break it into 5 smaller steps, therefore, we’d be checking for collisions at current location, 2m, 4m, 6m, 8m, and finally at 10m.

Why we need to do this and what’s the problem if we don’t?
Imagine there is a wall 6m ahead of the object. If we didn’t perform stepping, the object would have ended up directly from one side of the wall to the other without detection a collision. With stepping, we can now detect a collision when we are at one of the smaller steps when checking for collision at 6m.
Imagine the wall is 5m ahead instead. Now what would happen in this case? When we check for collision at 4m, they’re not touching yet, but what about at 6m? It could be touching, or we could have past it already, or we might have half our body stuck inside the wall. In this case, it might have been better, if we broke the steps into even smaller ones.

Deciding on an appropriate step size is very important. If the step size is too small, we might miss some collision, but if the step size is too big, it might slow down the update and other processes too much. I find that doing some trial and error helps to get a better understanding how much this stepping affects the overall performance. It can also help you figure out what the appropriate step size is too.

Here is a link to a demo which shows what happens when stepping into not used. The example is similar to the one I used to explain, about an object ending up in a wall.
http://matrix.senecac.on.ca/~pplam3/OSD/canvas3dapi-dev3/testDemo.html I’ve commited some code to the canvas3d repository that is the start of the new benchmarking tool. This tool picks up tests from the same file as the feature tester, but runs through them all sequentially in an automated fashion and prints the results. What is there now works, but is not feature complete. For instance, it doesn’t give a total for all the tests run. Also, it doesn’t yet support multiple models or tests that require interaction such as picking. Plus, the actual tests themselves need to be finished. It’s still just the light tests in there. I’ve refined the benchmarking a little so that the time between each call to Scene::render is dumped to the console.

Here’s a snippet of the results:
21 25 25 25 24 26 25 25 25 25
25 25 25 25 24 26 25 25 25 25
24 26 25 25 24 26 25 25 26 24
25 25 26 24 25 24 26 25 25 25
25
—> FPS: 41
24 25 26 25 25 25 25 25 24 26
24 26 25 26 24 25 25 25 192 25
25 25 25 25 24 26 25 25 24 26
25 25 25 25
—> FPS: 34

This shows calls to Scene::render over a two second period while the dummy canvas object is enabled. (I’m using a non-debug build of firefox this time because there may be some overhead from the printf in the garbage collector.) In the first second all calls take appoximately 25 milliseconds (which is the setInterval time). In the second second there is an oddball that takes 192 seconds. So it looks like it really only takes a 175 ms or so of garbage collection to throw off the animation.

I’ve created a new top-level directory in the repository called ‘tests’ and committed the beginnings of a new testing and benchmarking solution.

The idea is that developers can add a single function to a file and it will automatically get called by the test suite. The developer will write the function on the assumption that they are being passed a valid canvas object work with.

The tests in the file will be used in two ways. One is feature testing. The start of this is already in the repository to try out. Basically, every test function is run in both GLES11 and GLES20 contexts and the developer can click through the tests to see if everything looks right. I’ve added a few simple tests for lights effects so far. But I plan to do the picking, particles and physics too.

The second way (which is not yet committed) will be automated. In this case it is assumed that the developer has visually inspected the results. The tests will be run sequentially in one context at a time and performance data will be gathered.

I think it would also be a good idea to add some ordinary unit testing. Something where individual functions are tested just to make sure they are doing what they should be. But I want to get the other stuff done first.
I’ve added the capability to do benchmarking using a dummy canvas object. This should help us identify performance and memory problems easier. I’ve run a few tests with our standard benchmark using the dummy object to see how it affects our garbage collection problem. As you may recall, there is a short pause in the rendering which is believed to be caused by garbage collection.

I’ve put a printf into the Firefox garbage collector to give me console output telling me when it is running. Additionally, I’ve put a line of code into Scene::render to print out a single dot every it is called and modified the existing performance logging in Scene::render so it prints the frames per second to the console instead of the web page.

Here’s the result using the real canvas object:

………FPS: 14
.
*** gc running ***
–DOMWINDOW == 11 (0x13e57a0c) [serial = 10] [outer = 0x13d42220] [url = about:blank]
…………FPS: 13
…………..FPS: 14
…..
*** gc running ***

*** gc running ***
……….FPS: 15
……………FPS: 15
………….FPS: 13
…..
*** gc running ***
–DOMWINDOW == 10 (0x153218ac) [serial = 11] [outer = 0x13d42220] [url = http://www.mozilla.org/projects/minefield/]
……..FPS: 13
……………FPS: 15
……………FPS: 15
…………….FPS: 16
………….FPS: 13
………….FPS: 13
…………..FPS: 14
………….FPS: 13
………….FPS: 13
………….FPS: 13
…………..FPS: 14
………….
*** gc running ***
.FPS: 14
…………..FPS: 14
………….FPS: 13
………….FPS: 13
………….FPS: 13
…………..FPS: 14
………….FPS: 13
………….FPS: 13
………….FPS: 13
…………..FPS: 14
…………..FPS: 14
………….FPS: 13
…….
*** gc running ***
…FPS: 10
………….FPS: 13
…………..FPS: 14
……..
*** gc running ***
……FPS: 14
………….FPS: 13
………….FPS: 13
………….FPS: 13
…………..FPS: 14
…………..FPS: 14
………….FPS: 13
………….FPS: 13
…………..FPS: 14
…………..FPS: 14
………….FPS: 13
………….FPS: 13
………….FPS: 13
…………..FPS: 14
…………..FPS: 14
………….FPS: 13
………….FPS: 13
…………..FPS: 14
………….FPS: 13
…………..FPS: 14
………….FPS: 13
….
*** gc running ***
……FPS: 10
………….FPS: 13
…………..FPS: 14
………….FPS: 13
….
*** gc running ***
.

The points where the FPS drops to 10 is where a pause is happening. As you can see, this is where the garbage collection is happening.

Here’s the benchmark again, but this time using a dummy canvas object:

……………….FPS: 29
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
……..
*** gc running ***

*** gc running ***
…………………FPS: 29
………………………..FPS: 29
…………………………FPS: 30
………………
*** gc running ***
.
*** gc running ***
–DOMWINDOW == 10 (0x154058cc) [serial = 11] [outer = 0x13d25ba0] [url = http://www.mozilla.org/projects/minefield/]
.FPS: 20
………………………….FPS: 31
………………………..FPS: 29
………………………..FPS: 29
……………………….FPS: 28
………………………..FPS: 29
…………………………FPS: 30
………………………..FPS: 29
………………………..FPS: 29
…………………….
*** gc running ***
.FPS: 26
………………………..FPS: 29
……………………….
*** gc running ***
..FPS: 30
…………………………FPS: 30
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29

*** gc running ***
………………….FPS: 22
………………………..FPS: 29
…………………………FPS: 30
…………………………FPS: 30
………………………..FPS: 29
………………………..FPS: 29
………………………..FPS: 29
…………………
*** gc running ***
………FPS: 30
………………………..FPS: 29
…….
*** gc running ***
……………FPS: 22
…………………………FPS: 30
…………………………FPS: 30
………………………..FPS: 29
…………………………FPS: 30
………………………..FPS: 29
…………………………FPS: 30
………………………..FPS: 29
…………………………FPS: 30
………..
*** gc running ***
………..FPS: 22
…………………………FPS: 30
………………………..FPS: 29
…………………………FPS: 30
………..
*** gc running ***
……………….FPS: 30
………………………..FPS: 29
………………………..FPS: 29
…………………………FPS: 30
………………………..FPS: 29
……………..
*** gc running ***
…..FPS: 22
………………………..FPS: 29
………………………..FPS: 29
……………………..
*** gc running ***
.

In this case, all the code runs as usual, but there is no interaction with the canvas element at all. Because nothing is drawn to the canvas I can’t visually observe pauses, but I can see that the FPS falls sharply during garbage collection. If anything the effect is more pronounced at this speed.

At least this rules out the extension itself as the cause of the hiccup. Still to be determined is whether this is a problem that can be refactored out of our code, or if we’ve hit a limit in the implementation of javascript.