News for hackers. Stuff that matters.
Re:Babylon.js: JS framework for building 3D games with HTML5... by mistercow on Monday August 12, 2013 @01:43PM (#6200524)
This is really awesome, and it seems like proper WebGL games are going to become a common reality soon.

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.

Re:Babylon.js: JS framework for building 3D games with HTML5... by dtf on Monday August 12, 2013 @02:46PM (#6200901)
It seems to be pretty heavy on object allocation, eg:

    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.
Re:Babylon.js: JS framework for building 3D games with HTML5... by dirkk0 on Monday August 12, 2013 @02:52PM (#6200930)
Exactly - quote mrdoob: "We try really hard to not create or destroy objects at run time. We use pools and reuse objects as much as possible, or flags. We don't want to rely in the garbage collector." https://github.com/mrdoob/three.js/issues/2435#issuecomment-...
Re:Babylon.js: JS framework for building 3D games with HTML5... by deltakosh on Monday August 12, 2013 @03:01PM (#6200992)
The next version (1.2) will remove the pressure on GC by using in place operator and by reusing more entities
Re:Babylon.js: JS framework for building 3D games with HTML5... by dualogy on Monday August 12, 2013 @03:38PM (#6201169)
Makes me wonder why this isn't built on top of three.js to begin with?

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.

Re:Babylon.js: JS framework for building 3D games with HTML5... by pygy_ on Monday August 12, 2013 @02:04PM (#6200647)
The samples work fine is Firefox 22 too (30 to 60 FPS 1.8 GHz Core i5), without the pause you're describing.
Re:Babylon.js: JS framework for building 3D games with HTML5... by trycatch on Tuesday August 13, 2013 @03:33AM (#6204454)
There are pauses, even worse than in Chrome. Use MemChaser add-on to see GC activity in FF. In Firefox Nightly on the particle demo I have non-incremental 0.6-0.7s pauses every ~10s (not to mention stutter from incremental GC in between the big pauses). In Chrome on the same sample I just don't have any pauses longer than 0.1-0.2s (every ~2s).
Re:Babylon.js: JS framework for building 3D games with HTML5... by pyalot2 on Monday August 12, 2013 @03:15PM (#6201067)
Firefox has been working on an incremental GC
Re:Babylon.js: JS framework for building 3D games with HTML5... by mistercow on Monday August 12, 2013 @04:09PM (#6201423)
I believe that they have been using an incremental GC since version 16.
Re:Babylon.js: JS framework for building 3D games with HTML5... by kevingadd on Monday August 12, 2013 @08:50PM (#6203336)
Correct. In profiles I typically observe incremental GC running in 1-5ms increments, which makes it easier for it to fit in between frames without causing visible stutter.
Re:Babylon.js: JS framework for building 3D games with HTML5... by zanny on Monday August 12, 2013 @06:22PM (#6202566)
Firefox on a tf700 dies horribly at around 3 fps.

I wonder how webgl will perform on the predominant browser platform - mobile.

Re:Babylon.js: JS framework for building 3D games with HTML5... by kevingadd on Monday August 12, 2013 @08:49PM (#6203328)
I've been pushing for browser vendors to partially mitigate this by scheduling garbage collections during vsync (since the game's requestAnimationFrame code isn't running at that period in time). Unfortunately at present I'm not aware of anyone doing it.

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.