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.
This commit has handful of things going on:
- had to sacrifice one light to please ANGLE, making it again up to 4 instead of up to 5 total lights :(
- Basic / Lambert / Phong materials now have new parameters:
"combine": THREE.Mix | THREE.Multiply [default]
- tells how to combine environment map with the original material:
- "Multiply" creates chrome-like metallic look (it's what was already there),
color of the underlying material is multiplied with the environment map,
this creates different colored metals
- "Mix" creates shiny plastic look
color of the underlying material is lerped with the environment map,
amount of the contribution from the environment map is controlled
by another new parameter "reflectivity"
"reflectivity": <float> [from <0.0, 1.0>]
- controls mixing of underlying material and environment map for "Mix" combine mode
0: pure underlying material, zero contribution from environment map (Basic/Lambert/Phong)
1: pure environment map, zero contribution from underlying material (uncolored chrome look)
"refraction_ratio": <float>
- controls refractive mapping, ratio of the index of refraction in the medium containing the incident ray
to that of the medium being entered
- sensible values seem to be from ~0.6 - 1.0
(in theory, e.g. air/glass should be 0.75, but this looks weird, values between 0.9 - 1.0 give the most interesting results,
though maybe there is bug somewhere in my code)
- for use refraction mapping, just add parameter to TextureCube like this (default is reflection mapping)
"new THREE.TextureCube( images, THREE.RefractionMap )"
At first I though the cube around the sphere was x-inverted (unless the in tention is to simulate refraction...) I've tried changing that but the effect is still weird. I guess those textures work mainly for the sphere and not for the panorama.
I reused the code and did another example using the skymap. More to come ;)
I can see some lines at the edges of the planes though. I guess that's antialiasing kicking in. Should be fixed with a proper cube mesh I guess.
CanvasRenderer has a property called `autoClear` which is true by default. By making it false you have control of when the renderer cleans the screen (by calling renderer.clear()). I wonder if something like that can be added to the WebGLRenderer? That way we can render the cube outside the spheres from a diferent camera (centered in the middle of the screen) than the spheres floating.
Also, added `shading` parameter to `MeshBasicMaterial` (environment mapping was being rendered faceted when using `MeshBasicMaterial` because `shading` was missing (and thus Faceted)).
TODO:
- maybe image array loader should go into TextureCube.js so that people could just reuse the code
- it may be worth to be able to specify different combination of environment map and underlying material (in single render pass),
currently color/color map/environment map are multiplied, though addition also produces very interesting looking materials
Cloned materials.html -> materials_gl.html to have easier test for WebGLRenderer.
TODO:
Investigate why this test is so slow. It shouldn't be, materials_shaders.html is more complex and yet it is much faster (36 vs 60 fps).
MeshFaceMaterial with every face different is pretty bad use case for WebGLRenderer, but this still doesn't fully explain slowdown :(.
This is actually tricky due to multimaterials and vertex normals.
The practical effects of "shading" parameter in WebGLRenderer are currently following:
- if your model has vertex normals, now you can "dumb down" its shading by specifying THREE.FlatShading for MeshLambertMaterial and MeshPhongMaterial
- if your model has only face normals, it will always have just flat shading, no matter which shading you set, no escape from this
- if your model has multiple materials, smooth shading always "wins", meaning if there is at least one smooth shaded material in multimaterial group, all other materials in this group will be also smooth shaded (this is solvable by having multiple normal buffers, but seems wasteful, at least for the moment, till there are no practical use cases)
Currently implemented shading / material combinations:
- MeshNormalMaterial: FlatShading [default], GouradShading
- MeshDepthMaterial: no shading parameter in material, uses own specific shading
- MeshBasicMaterial: no shading parameter in material, uses own specific shading
- MeshLambertMaterial: FlatShading, GouraudShading [default]
- MeshPhongMaterial: FlatShading, PhongShading [default]
It's commented out, as it breaks shader validation in current Chrome :(.
There seems to be some bug in Chrome / ANGLE making it barf when using "gl_FragCoord" in fragment shader.
Curiously, while it breaks both 9.0.576.0 dev channel and latest continuous build 9.0.583.0, it does work fine in canary build with the same version as dev channel (9.0.576.0).
Go figure. Also in Firefox 4 beta 7 it works fine.
It seems there were some recent changes in handling of "gl_FragCoord" on Windows which probably broke something when fixing other bug:
http://code.google.com/p/chromium/issues/detail?id=59762http://code.google.com/p/angleproject/issues/detail?id=71
TODO: make isolated test case and submit bug report (if this doesn't go away in next Chrome update).
alteredq
Mr.doob