- 27 1月, 2011 1 次提交
-
-
由 alteredq 提交于
Also shader program building is now spread over loading time.
-
- 24 1月, 2011 1 次提交
-
-
- 20 1月, 2011 1 次提交
-
-
由 astrodud 提交于
created _m33 class member (moved out of Matrix4) and modified THREE.Matrix4.makeInvert3x3() call accordingly
-
- 18 1月, 2011 3 次提交
-
-
由 Mr.doob 提交于
-
由 alteredq 提交于
This should be the last place where new arrays were created in "render". Chrome memory now seems stable. Firefox still grows like mad, though this used to be like this also with other demos (simply setting random values to existing arrays does this). Seems like Mozilla folks themselves struggle with this: http://www.flickr.com/photos/11280278@N04/5363335103/in/photostream/
-
由 alteredq 提交于
See discussion here: https://github.com/mrdoob/three.js/issues#issue/92
-
- 17 1月, 2011 1 次提交
-
-
由 alteredq 提交于
Also doesn't seem to decrease performance so far (though most of demos have small number of objects).
-
- 16 1月, 2011 1 次提交
-
-
由 alteredq 提交于
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 )"
-
- 15 1月, 2011 1 次提交
-
-
由 alteredq 提交于
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.
-
- 14 1月, 2011 2 次提交
-
-
由 alteredq 提交于
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 :(
-
由 alteredq 提交于
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 ;).
-
- 13 1月, 2011 1 次提交
-
-
由 alteredq 提交于
Added dynamic geometry support also for WebGL lines. Changed line strip example to use Hilbert curves. Also fixed tons of bugs in lines handling. TODO: make some example for dynamic lines.
-
- 12 1月, 2011 1 次提交
-
-
由 alteredq 提交于
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.
-
- 11 1月, 2011 1 次提交
-
-
由 Szymon Nowak 提交于
-
- 10 1月, 2011 1 次提交
-
-
由 Szymon Nowak 提交于
-
- 09 1月, 2011 2 次提交
-
-
由 alteredq 提交于
Also some refactoring of initWebGLObjects slipped in this commit.
-
由 alteredq 提交于
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.
-
- 08 1月, 2011 1 次提交
-
-
由 alteredq 提交于
Refactored handling of continuous lines: now they are rendered using LINE_STRIP primitive. Added example for this. Also renamed associated constant to THREE.LineStrip (was THREE.LineContinuous).
-
- 06 1月, 2011 1 次提交
-
-
由 alteredq 提交于
-
- 04 1月, 2011 1 次提交
-
-
由 alteredq 提交于
As expected, performance of one-to-one conversion from CanvasRenderer was horrible, so I had to change a bit how lines are handled. Line object now has "type" property: - default type is "THREE.LineContinuous" which should behave as before: geometry represents one continuous line (v0 ... vn) - new option is "THREE.LinePieces" which tells renderer that geometry represents collection of individual line segments (v0,v1) ... (vn-1, vn) (one Line object corresponds to one VBO) (same limitations as with meshes - once VBO is baked, no changes are possible except object transforms - scale / rotation / position)
-
- 03 1月, 2011 1 次提交
-
-
由 alteredq 提交于
-
- 31 12月, 2010 2 次提交
-
-
由 alteredq 提交于
-
由 alteredq 提交于
Code is still rough around edges (it can be made nicer), though it should already produce one-to-one results with ubershader. Side-effect is that scene is no longer required as WebGLRenderer constructor parameter. Shader programs are now constructed upon first frame render and only then scene lights are examined.
-
- 30 12月, 2010 4 次提交
-
-
由 alteredq 提交于
-
由 Mr.doob 提交于
Added a shader demo (as in using only 2 triangles).
-
由 alteredq 提交于
One more to go ;) Mess / code duplicities are temporary, hopefully they will go away once also Phong uses the same machinery.
-
由 Szymon Nowak 提交于
-
- 29 12月, 2010 2 次提交
-
-
由 alteredq 提交于
None of the demos seem to be slower, some are noticeably faster (especially terrain). I suspect biggest performance gain comes from conditional include of environment mapping: if it's not used, it doesn't go into shader at all.
-
由 alteredq 提交于
Refactored uniforms cloning into separate file so that it can be reused also for MeshShaderMaterials. 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.
-
- 28 12月, 2010 1 次提交
-
-
由 alteredq 提交于
TODO: start using uniforms cloning also for MeshShaderMaterials.
-
- 27 12月, 2010 1 次提交
-
-
由 alteredq 提交于
This is necessary for having multiple materials using the same shaders with different parameters.
-
- 26 12月, 2010 3 次提交
-
-
由 alteredq 提交于
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.
-
由 alteredq 提交于
This allows to work around ANGLE antialiasing issue appearing when compositing WebGL framebuffer with transparent background color with HTML canvas element background (while keeping antialiasing on). WebGLRenderer constructor now takes JSON object with few optional parameters: renderer = new THREE.WebGLRenderer { scene: scene, antialias: true, clearColor: 0x000000, clearAlpha: 0 }; Here is how to change clear color in runtime: renderer.setClearColor( 0xff0000, 1 );
-
由 Mr.doob 提交于
Moved near/far values from MeshDepthMaterial to Camera (CanvasRenderer/WebGLRenderer/WebGLRenderer2).
-
- 25 12月, 2010 2 次提交
- 24 12月, 2010 1 次提交
-
-
由 alteredq 提交于
This is a workaround for Chrome ANGLE antialiasing issue manifested in geometry_terrain_fog demo: http://twitpic.com/3iftyh Problem happens in Chrome ANGLE when geometry is rendered with the same color as canvas background - then instead of expected nothing to be seen, there is a faint white outline at geometry borders. This issue is not specific to fog, even just rendering geometry with MeshBasicMaterial having the same color as background produces the same outline. TODO: create isolated test case and file ANGLE / Chromium bug.
-
- 21 12月, 2010 3 次提交
-
-
由 alteredq 提交于
-
由 alteredq 提交于
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 :(
-
由 Mr.doob 提交于
-