There is a new class Edge which stores vertices and faces for edge (I wasn't sure if indices or references would be better, so at least for the moment it contains both).
Geometry now contains a list of such edges, created in JSONLoader, based on edge data exported from Blender.
From Blender we get a list of vertex index pairs, from which in Geometry.computeEdgeFaces() we compute faces which share this particular edge and store them in the Edge object.
Not sure if edges work properly till we don't have something using them. For now I just checked cube data exported from Blender and it seems fine.
Also did some whitespace cleanup here and there.
PathCamera automatically follows path passing through waypoints (interpolated via Catmull-Rom spline). View angles can be constrained and controlled by mouse.
Work in progress, there are still some issued to be solved (constant movement speed, broken automatic update, broken frustum culling).
If no object is passed to initMaterials (for example, if material is pre-built while loading, or shader program is intended for sharing), max limit of 50 bones is used (should be enough to leave space for other uniforms not to hit ANGLE limits).
Now you can add keyboard + mouse camera control with a single line, just change camera type and add parameters:
camera = new THREE.QuakeCamera( { fov: 50, aspect: window.innerWidth / window.innerHeight, near: 1, far: 10000,
movement_speed: 1, look_speed: 0.002, nofly: true, look_vertical: false } );
Thanks to mrdoob for suggestions ;)
build/Three.js - Includes all renderers + extras
build/custom/ThreeCanvas.js - Canvas renderer only
build/custom/ThreeDOM.js - DOM renderer only
build/custom/ThreeSVG.js - SVG renderer only
build/custom/ThreeWebGL.js - WebGL renderer only
build/custom/ThreeExtras.js - Extras only
Moved `THREE.Detector.js` to `examples/js/Detector.js`.
Updated examples to reflect these changes.
It provides a lean way how to render TRIANGLE_STRIP primitives: needs just n+2 vertices for n triangles (one Ribbon = one strip). There are no faces, no indices, everything is rendered in one simple drawArray call.
Vertex colors are supported, normals not yet.
We have been very lucky - setters / getters were not supported till just 2 hours ago (so fresh, I had to build Closure myself from their repo ;).
http://code.google.com/p/closure-compiler/issues/detail?id=249
Also some refactoring plus added hackish animation offset feature.
Created "THREE.Supports" object, which should centralize this stuff. So far it detects <canvas>, WebGL and WebWorkers; later it could detect for example GPU capabilities.
Not sure about name or location, but it's pretty tiring go through all examples when something changes, so it should be somewhere in the library.
Code duplication is bad: even html snippets with error message should be centralized somewhere, so that when new browsers arrive we wouldn't have to keep changing them in many places.
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.
Also changed MeshShaderMaterial demos to show how to use cloning. For these particular demos uniforms cloning is not really necessary as they use only one instance of shader material, but for example, if there were two normal mapped models in one scene, each model would need separate material with own uniforms.
For the moment, only one type of fog is baked into shader, depending on scene.fog initial value.
If use case arise for dynamic fog type switching, this could be changed, though than both fogs would need to be computed all the time :S.
For the moment, it works just on Basic / Lambert / Phong materials.
Fog must be added to the scene before initialization of WebGLRenderer and scene must be passed to WebGLRenderer constructor (like for lights).
I don't know yet how to solve properly MeshShaderMaterial & co :(
Instant performance boost in all cube mapping demos ;)
With panoramas there were insane amounts of unnecessary computations done in fragment shader - basically every pixel on the screen was computing the whole ubershader - ouch ouch ouch!
This was the lowest hanging fruit, still some more performance can be gained by removing other stuff from ubershader.
Big thanks to mrdoob for starting to question sanity of ubershader ;)
alteredq
Bartek Drozdz
Mr.doob
Mikael Emtinger
astrodud
Szymon Nowak