It works more or less the same as lines:

  - particles are passed to ParticleSystem object as geometry
  - material is ParticleBasicMaterial (textures should be supported, not tested yet)
  - geometry can be updated by setting "__dirtyVertices" property of the geometry

Work in progress ...

Made CanvasRenderer ParticleBasicMaterial handling consistent with the rest — material.map needs to be a Texture.

Also shader program building is now spread over loading time.

https://github.com/mrdoob/three.js/pull/97

This should be the last place where new arrays were created in "render".

Chrome memory now seems stable.

Firefox still grows like mad, though this used to be like this also with other demos (simply setting random values to existing arrays does this).

Seems like Mozilla folks themselves struggle with this:

http://www.flickr.com/photos/11280278@N04/5363335103/in/photostream/

See discussion here:

https://github.com/mrdoob/three.js/issues#issue/92

For the moment just things that are executed every frame in WebGLRenderer.render.

Continuing with quest to minimize creation of new data structures. Should instead create per class/object structures and just reuse them (as gman does in ThreeD). Main goal is to avoid annoying garbage collection pauses.

Let's hope it didn't break something (could be if some code was dependent on cloning of return values of "flatten" or "makeInvert3x3", though from what I checked these are just used to set typed arrays uniforms).

Also doesn't seem to decrease performance so far (though most of demos have small number of objects).

Testing on current examples didn't show any noticeable performance degradation when enabling / disabling culling for every object in every frame.

"FlipSided" property could be probably done in very similar way, just setting "gl.frontFace( gl.CCW )" or "gl.frontFace( gl.CW )"

For this had to extend WebGLRenderer a bit:

- MeshShaderMaterial now can take non-specific float array uniforms as "fv1"
  (there is already "fv" type for array of 3-item-vectors, which probably should be renamed to "fv3" to be consistent)

- render method has yet another parameter "clear" for clearing newly set framebuffer (defaults to true).
  This is a bit hackish but it seems necessary to control this somehow. I didn't manage to replicate
  desired behavior just with autoClear.

- another dirty thing is accessing GL context from the application side:
    renderer.context.disable( renderer.context.DEPTH_TEST );

    This should be refactored somehow, wrapped in some API call.

Rendering proper 3d object into the texture uncovered another issue - framebuffer had to be cleared after switching.

Texture is still flipped :( (original scene has small red torus on the top)

This is proving to be rather tricky. Yet again I tried to handle image coordinate mess in a proper way (UNPACK_FLIP_Y_WEBGL as texture parameter and non-inverted UVs), fixing hacks across the codebase.

This did indeed help with render-to-texture flipping, but instead it created really ugly problems with both normal map and minecraft AO demos. So back to square one :(

Had to set viewport to make it work in OpenGL.

Also made it easier to see texture orientation in the example.

Now it's visible that there is indeed flipping. At least now it's consistent ;).

Added dynamic geometry support also for WebGL lines. Changed line strip example to use Hilbert curves.

Also fixed tons of bugs in lines handling.

TODO: make some example for dynamic lines.

If you want to refresh VBOs (and thus have geometry changes reflected in renderer), you need to set dirty flags on geometry object.

There are separate flags for different buffers (as not always all buffers need to be updated and oh my is updating costly):

    mesh.geometry.__dirtyVertices = true;
    mesh.geometry.__dirtyNormals = true;
    mesh.geometry.__dirtyUvs = true;
    mesh.geometry.__dirtyTangents = true;

    mesh.geometry.__dirtyElements = true;

That was quite tough feature, a lot of refactoring, yet performance is still quite bad :(

The biggest remaining bottleneck seems to be translation between Three.js internal data formats and buffers. I removed as much per-frame arrays creation as I could, but even just iterating through existing data and setting of values is still very costly. Also per-frame normals computation is expensive.

Also some refactoring of initWebGLObjects slipped in this commit.

No need to stuff them in different bucket, line-specific stuff is anyway done in `renderBuffer` method.

This was prompted by starting with implementation of ParticleSystem. It would be unwieldy to handle three different buckets of objects / buffers.

Refactored handling of continuous lines: now they are rendered using LINE_STRIP primitive. Added example for this.

Also renamed associated constant to THREE.LineStrip (was THREE.LineContinuous).

As expected, performance of one-to-one conversion from CanvasRenderer was horrible, so I had to change a bit how lines are handled.

Line object now has "type" property:

    - default type is "THREE.LineContinuous" which should behave as before: geometry represents one continuous line (v0 ... vn)

    - new option is "THREE.LinePieces" which tells renderer that geometry represents collection of individual line segments (v0,v1) ... (vn-1, vn)

(one Line object corresponds to one VBO)

(same limitations as with meshes - once VBO is baked, no changes are possible except object transforms - scale / rotation / position)

loader.loadAscii and loader.loadBinary now take just one parameter with following properties:

    - model (required)
    - callback (required)
    - texture_path (optional: if not specified, textures will be assumed to be in the same folder as JS model file)
    - bin_path (optional: if not specified, binary file will be assumed to be in the same folder as JS model file)

Example use:

    loader.loadBinary( { model: "model.js", bin_path: "path/bin", texture_path: "path/img",
                         callback: function( geometry ) { createScene( geometry ) } } );

Updated README.