MeshShaderMaterial is still work in progress, expect changes.
Nice side effect of WebGLRenderer refactoring: optimized one significant bottleneck (with noticeable effect on framerate in some demos), typed arrays corresponding to matrix uniforms are now set (instead of being created anew in each frame).
Also created fully full build, with all extras included. This helps with deployment, especially when multiple versions of Three have to coexist in the same folder structure (got burned on this few times already).
2d texture encapsulates bitmap, wrapping and minifying/magnification parameters.
Which reminds me, maybe also minifying/magnification options should be parameters in Texture object.
Though as defaults are "best" (LINEAR / LINEAR_MIPMAP_LINEAR = trilinear filtering), this would make sense just for special use cases like when trying to achieve "retro" look (like in Minecraft, http://gregs-blog.com/2008/01/14/how-to-turn-off-bilinear-filtering-in-opengl/ ;).
Turns out it is working better over the real web than on localhost (where it seems loading is too fast for Chrome to pick up UI changes, so it queues them and shows them all just after loading is already finished).
Still not working properly - getting length of full content, this seems to be unreliable across browser / server combination.
Instead passing to callback JSON object with both total and loaded bytes, so this can be handled in the application layer:
{ total: bytes_total, loaded: bytes_loaded }
To be used e.g. like this:
loader.loadBinary( url, function( geometry ) { createScene( geometry ) }, path, updateProgress );
function updateProgress( progress ) {
var message = "Loaded ";
if ( progress.total ) {
message += ( 100 * progress.loaded / progress.total ).toFixed(0) + "%";
} else {
message += ( progress.loaded / 1000 ).toFixed(2) + " KB";
}
$( "status" ).innerHTML = message;
}
Not anymore automatic, but also much less wasteful.
Has to be called in tandem with scene object removal:
scene.removeObject( object );
webglRenderer.removeObject( scene, object );
The order of render passes is now following:
1. opaque materials with normal blending
2. opaque materials with additive blending
3. opaque materials with subtractive blending
4. transparent materials with additive blending
5. transparent materials with subtractive blending
6. transparent materials with normal blending
With growing number of passes it's possible it may be worth to do some pre-sorting, though it would have to be tested.
Current way is fairly cheap as if there are no corresponding materials in the pass, for loops just blast through (potentially many very cheap operations).
Pre-sorting would mean creating arrays on the fly in each frame (one expensive operation with effect on garbage collection, which especially Firefox is currently very bad at).
Also moved loadImageArray utility function from examples into TextureCube.js
To be used like this:
var urls = [ "px.jpg", "nx.jpg", "py.jpg", "ny.jpg", "pz.jpg", "nz.jpg" ];
var images = THREE.loadImageArray( urls );
var textureCube = new THREE.TextureCube( images );
// create scene
var objectMaterial = new THREE.MeshBasicMaterial( { color: 0xffffff, env_map: textureCube } )
createScene( objectMaterial );
// create panorama
var size = 100000;
var panoMaterial = new THREE.MeshCubeMaterial( { env_map: textureCube } );
var mesh = new THREE.Mesh( new Cube( size, size, size, 1, 1, null, true ), panoMaterial );
sceneCube.addObject( mesh );
Warning: this functionality is currently changing a lot, expect things to get broken before stabilization.
Mr.doob
alteredq
timk