Also, removed GeometryLoader. I'll try doing the JSONLoader to GeometryLoader change again in the future.

See #2623.

Without CubeGeometry is a little bit easier to follow. Wasn't sure whether doing it like this or using a single material/texture with modified UVs per side.
Also, I've had to comment out some code from GeometryUtils that asumed object2 to be a mesh.

See #2628 and #2623

Bumped scene format version to 3.2

Modified correspondingly SceneLoader, SceneExporter, Blender scene exporter and example scene files.

See #2628

Testing the impact of normalization of transformed normals in vertex shaders (phong, normal, normalmap, skin simple).

It seems the effects on performance are minimal: in several random examples it's either not measurable, or just a tiny bit worse.

See #2613

Fixed implications of new MeshFaceMaterial.materials at multiple places (Ray, Projector, ShadowMapPlugin, DepthPassPlugin).

Thanks to @WestLangley for vigilance (see #2623).

Patch to #2623

I believe this is not needed anymore.

Also for the moment in depth pass skipping all ParticleSystems without custom depth material. Otherwise there are GL errors, need to create a proper generic depth material for particles.

See discussion at https://github.com/alteredq/three.js/commit/5cb715520806a5afa1057a31a6777c2e454eeff0

This is necessary for OpenGL where pow(0,0) is undefined and can be negative (in DirectX you just get zero), leading to negative light creating black areas artefacts.

Fixes #1805 and #2615 (related already fixed #998).

See discussion in #2613

Finally I just left it behind a flag. I was not able to get as good results for TextGeometry as with unweighted method and split materials for side and front faces.

I wonder how I got that nice look as in screenshot I posted in the issue. It still does look better with weighted than unweighted but nowhere so close as in that screenshot. Either I did some mistake when testing before or there is some bug in implementation now.

See #2610

Small fix to #2610

Because that's what it is.

Now it should look the same no matter where the object is located.

In the process found some issues:

- HemisphereLight shading is wrong for objects not in origin, it shouldn't depend on light position amplitude and object position in the scene
- GL errors about uniforms thrown when all lights have "visible = false"
- object dragging in the viewport sometimes hits invisible wall (I guess it's because of limited picking plane size?)
- ArrowHelper doesn't seem to work for (0,-1,0) direction

Also fixed spotlights shading in Lambert material and light helpers init colors for light intensities > 1.

Please disregard init scene lighting weirdness, this is just temporary, to be able to test light helpers.

This is for PointLights.

Also removed unused distance property from DirectionalLight class (at least I think so, I know WebGL materials don't use this and I couldn't find it used elsewhere).

Added rays also to DirectionalLightHelper.

Refactored PointLightHelper and DirectionalLightHelper.

Also added one PointLight to dummy starting scene to be able to test point lights (at least while there is no UI for adding lights).

Changed multiple gizmos not to be affected by fog.

Made DirectionalLightHelper constructor take sphere size as a parameter.

Fixes #2600

Not yet 100% sure about all the details but this is something that should be useful for making helpers prettier.

This makes it safer to compile shaders without maxLights cap. Only per vertex phong code path is sensitive to available number of varyings (together with shadow maps, but you would need to be pretty crazy to have enough shadowed lights to hit varying limits).

Also like this phong material behaves more as expected for large polygons.

Performance wise, for many use cases and systems it's actually similar or even faster.