BABYLON.Vector3.prototype.add = function (otherVector) {
return new BABYLON.Vector3(this.x + otherVector.x, this.y + otherVector.y, this.z + otherVector.z);
};
I do a lot of WebGL work and I'm constantly fretting about avoiding allocations. For instance, compare to gl-matrix's operator: vec3.add = function(out, a, b) {
out[0] = a[0] + b[0];
out[1] = a[1] + b[1];
out[2] = a[2] + b[2];
return out;
};
A little more awkward, but you're only allocating the vector once and then modifying in place wherever possible. THREE.js takes as similar approach with THREE.Vector3.Three has well over 2 years of rock-solid improvements under its belt, from hardcore graphics programmers to boot.
Three is not a fully fledged game engine, it's "only" providing a reasonably easy to use, sane 3D graphics engine to run on, which raw WebGL is decidedly not.
So any JS "game engine" project would do well to build on three.js (to pick up their many performance and other improvements from the last 2-3 years and those that the community will keep producing over the years to come) and then on top of that provide actual, non-rendering related "game engine" features akin to Unity3D. Objects management, component system, triggers, events, usable input management abstractions, materials management, LOD systems, configurable shadowing/lighting setups (on top of the options provided by three+friends), pluggable post-fx shaders with a few out-of-box ones and easy custom shader integration etc etc etc.
I wonder how webgl will perform on the predominant browser platform - mobile.
For reference, at 60hz you have roughly 16.6ms to produce a frame and then do whatever you like before it's time to present it. So if the actual game code runs in a few milliseconds (not unreasonable for low to mid tier 3d games, even in the browser), you can do some incremental GC for 5-10ms and not be at risk of missing vsync. It's even better if you do the actual wait-for-vsync in a dedicated thread while you GC; then you won't ever miss vsync, and the vast majority of GC pauses are entirely hidden from the user.
Chrome handles these samples very well, except for one thing which I think would be a major distraction for games: there's a ~1/sec stutter, which I assume is a GC pause. Google touts their stop-the-world GC as being ultra efficient and accurate, and in many ways it is. But I'm not sure that STW is an appropriate approach for games.
The stutter has improved in recent updates, but it's still there. I wonder if they'll consider an alternative GC approach for situations involving continuous rendering.