This is a workaround for Chrome ANGLE antialiasing issue manifested in geometry_terrain_fog demo:

http://twitpic.com/3iftyh

Problem happens in Chrome ANGLE when geometry is rendered with the same color as canvas background - then instead of expected nothing to be seen, there is a faint white outline at geometry borders.

This issue is not specific to fog, even just rendering geometry with MeshBasicMaterial having the same color as background produces the same outline.

TODO: create isolated test case and file ANGLE / Chromium bug.

WebGLRenderer2: Fixed a possible issue when modifying scene parameters and having only one program (thx alteredq)

Projector::projectScene now does a first pass through Projector::projectObject (which does frustum culling and object sorting).
So now CanvasRenderer and SVGRenderer feature frustum culling too.

For the moment, it works just on Basic / Lambert / Phong materials.

Fog must be added to the scene before initialization of WebGLRenderer and scene must be passed to WebGLRenderer constructor (like for lights).

I don't know yet how to solve properly MeshShaderMaterial & co :(

Starting to prepare stuff for adding Fog. Having Fog.js inside /scenes doesn't sound right, but I guess it can be there for now...
The idea would be to do `scene.fog = new THREE.Fog( color, near, far );` This way seems consistent with the rest of the API. By default `scene.fog` is `null`.

Depth material finally works also in ANGLE.

Added `boundingBox`, `boundingSphere` and `computeBoundingSphere` to Geometry.

Added `sortElements` boolean (true by default) to `CanvasRenderer` and `SVGRenderer`. Also added `sortObjects` boolean but not being used yet.

Projector sort boolean is now required (CanvasRenderer and SVGRenderer updated).

Instant performance boost in all cube mapping demos ;)

With panoramas there were insane amounts of unnecessary computations done in fragment shader - basically every pixel on the screen was computing the whole ubershader - ouch ouch ouch!

This was the lowest hanging fruit, still some more performance can be gained by removing other stuff from ubershader.

Big thanks to mrdoob for starting to question sanity of ubershader ;)

Instant performance boost by 50% ;).

This one kept me puzzled for days. Premature optimization is indeed evil.

Manifestation was that MeshShaderMaterial mysteriously didn't work depending on what was going on elsewhere in the scene. I think mrdoob's problem with "basic" shader was caused by this bug.

WebGLRenderer2 now uses Projector too (projecting objects + sorting, to slightly avoid transparency sorting glitches).

Added a check in `Scene` to make sure the avoid duplicate objects.
WebGLRenderer2: In the process of handling > 65535

Made 0xffffff the default color on all materials (0xeeeeee was making the AO a bit darker).

Thanks to Paul Irish for gist:

https://gist.github.com/a9ce964c4dcd08aee976/63562a89d78d44b3a96e37dd361e1a65f51cb559

For some reason it doesn't work with the current Chrome canary (10.0.607.0) when using ANGLE :(.

Also OBJ converter demo is having problems with generated tiled texture in latest canary, so it looks like some bug was introduced in ANGLE's handling of UVs (baked AO relies on "zoomed" UVs).

Need to investigate more, maybe file a bug report.

Added textures

Switched to the normalToComponent formula the CanvasRenderer uses.

Added MeshNormalMaterial.
Moved mColor * mOpacity computation to the shader.

Yet again that misterious behaviour where stuff gets pasted in weird places. Long time without experiencing it...

WebGLRenderer optimisation: flattening camera matrices just once per render, it was doing it once per object before.
WebGLRenderer2: Trying to re-create WebGLRenderer from scratch... Creating a program per material instead of just one for everything. Seems to be 3x faster by now...

Added `lights_pointlight_smooth` example. To be used for tracking browser improvements affecting that technique.