Renamed: setClearColor( hex, opacity ) => setClearColorHex( hex, opacity )
New: setClearColor( color, opacity )
In this way it's a bit cheaper to animate clear color.
Hope I didn't break examples - I searched for "setClearColor" and changed it in one place where it was used.
Work in progress, caveats:
- sort happens just inside one ParticleSystems, so everything gets messed up when more ParticleSystems are in the same screen space
- not yet solved proper order of operations, if you change object transform, you need to update ParticleSystem object matrix manually before rendering (so that sort works, otherwise it will use transform from previous frame)
Also fixed transparency in fog and did small optimizations in WebGLRenderer.
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
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.
Requires to turn off mipmapping to be able to use non-power of two texture.
Effect of texture size on performance is noticeable, also there is no antialiasing (default in Chrome is I think 4x multisampling).
So I guess full-screen postprocessing will be quite costly :(. That's the price of WebGL always running at full-blown high resolution.
This could be somehow mitigated by faking lower resolutions via smaller texture, though I guess it still wouldn't be the same as having lower resolution set by GPU driver (this is a major help with performance in games - I never run full 1680 x 1050).
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 ;).
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.
alteredq
Mr.doob
Szymon Nowak