- 03 11月, 2010 2 次提交
- 02 11月, 2010 1 次提交
-
-
由 Mr.doob 提交于
-
- 01 11月, 2010 3 次提交
-
-
由 alteredq 提交于
Fixed ambient light computation in CanvasRenderer to get correct lighting when there is no ambient light specified in the scene.
-
由 alteredq 提交于
-
由 Mr.doob 提交于
* Clickresolver.js: Implemented blackpawn's point in triangle algos ( http://www.blackpawn.com/texts/pointinpoly/default.html ). Now works properly with Face3 too.
-
- 31 10月, 2010 12 次提交
-
-
由 Mr.doob 提交于
Now we just need to make sure geometry.computeCentroids() is called at the end of creating/modifying the geometry, otherwise things break...
-
由 Mr.doob 提交于
* Projector.js: Rather than calculating the screen space centrium of each face per render, seemed smarter to just project the precomputed centrium. Side effect: Polygon shaking is gone \o/
-
由 alteredq 提交于
-
由 Mr.doob 提交于
-
由 alteredq 提交于
-
由 alteredq 提交于
Added face culling to WebGLRenderer (default is now backface culling on, front face is counter-clockwise). Thanks to mrdoob for noticing :)
-
由 alteredq 提交于
-
由 Mr.doob 提交于
-
由 alteredq 提交于
-
由 Mark DiMarco 提交于
-
由 alteredq 提交于
Limitations: - Chrome can handle up to 5 lights in total (directional + point) - Firefox seems to handle up to 29 lights These number are GPU specific (mine is ATI Mobility Radeon 3650). This turned out to be quite tricky. The number of varying vectors in shaders is limited. Additionally Chrome and Firefox have different limitations (at least on Windows, probably due to Chrome using ANGLE as rendering backend). Hence WebGLRenderer has hardcoded limit of maximum 5 lights. WebGLRenderer constructor now takes (optional) scene argument, so that numbers and types of lights present in the scene can be used to generate minimal possible shader. If no scene is passed, shader allowing 1 directional + 4 point lights will be generated.
-
由 Mr.doob 提交于
-
- 30 10月, 2010 5 次提交
- 29 10月, 2010 10 次提交
-
-
由 Mr.doob 提交于
-
由 alteredq 提交于
-
由 alteredq 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
* Minor fixes (Geometry normal calculation) * Isolated Matrix3 code into `Matrix3.js` * README and TODO updated
-
由 alteredq 提交于
Changed OBJ -> Three.js converter to use new materials system (eventual old models need to be reconverted). Limitations: - one use case is now much slower - when a mesh has each face with different color (e.g. polyfield in examples/test.html) - before this used FaceColorFill material and in WebGLRenderer it was rendered fast with color attribute array - now when FaceColorFill material is gone, each face gets own VBO :( - material sorting uses Materials "toString" methods for hashing, so it's very important to keep these in a good shape
-
- 28 10月, 2010 2 次提交
- 27 10月, 2010 2 次提交
-
-
由 alteredq 提交于
Changed camera matrix update in WebGLRenderer to happen just once per frame, no need to do it with every object.
-
由 Mr.doob 提交于
* MeshBitmapUVMappingMaterial -> MeshBitmapMaterial. Second param is mode, which is THREE.MeshBitmapMaterialMode.UVMAPPING by default. * Removed MeshFaceColorFillMaterial and MeshFaceColorStrokeMaterial * Added MeshFaceMaterial ( it uses the face.material for that pass ) * CanvasRenderer and SVGRenderer per face material logic changed. * SVGRenderer supports particles again. * WebGLRenderer currently broken :/ * Code clean up
-
- 26 10月, 2010 3 次提交
-
-
由 alteredq 提交于
Premultiplied alpha in WebGLRenderer for MeshColorFillMaterial and MeshColorStrokeMaterial (to get closer to CanvasRenderer look).
-
由 alteredq 提交于
Refactored multimaterials to also work with non-textured models composed from multiple material groups. Old version was doing massive overdraw (whole mesh was drawn for each material). Even current solution is still quite messy: there is a different behavior for stroke and fill materials (when used as secondary materials). Stroke materials are applied to the complete mesh (as most common use case seems to be wireframe) while fill materials now apply only to faces within single material group (when "decalIndex" property of secondary fill material is set).
-
由 alteredq 提交于
There were two problems: - vertices were in a different coordinate system than normals - generated JS code was not properly handling normals with 0-sized components
-