- 16 1月, 2011 2 次提交
- 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 6 次提交
-
-
由 alteredq 提交于
Requires to turn off mipmapping to be able to use non-power of two texture. Effect of texture size on performance is noticeable, also there is no antialiasing (default in Chrome is I think 4x multisampling). So I guess full-screen postprocessing will be quite costly :(. That's the price of WebGL always running at full-blown high resolution. This could be somehow mitigated by faking lower resolutions via smaller texture, though I guess it still wouldn't be the same as having lower resolution set by GPU driver (this is a major help with performance in games - I never run full 1680 x 1050).
-
由 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 提交于
Still flipped, though at least now it's consistent.
-
由 alteredq 提交于
-
由 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 ;).
-
由 alteredq 提交于
Something is broken as OpenGL shows different result than ANGLE :( Though this time it's ANGLE which seems correct.
-
- 13 1月, 2011 2 次提交
-
-
由 alteredq 提交于
This is untested, as example is in different branch, have to commit this merge first. At least this didn't seem to break existing things.
-
由 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 2 次提交
-
-
由 alteredq 提交于
-
由 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 6 次提交
-
-
-
由 oosmoxiecode 提交于
-
由 oosmoxiecode 提交于
-
由 oosmoxiecode 提交于
-
由 Szymon Nowak 提交于
-
由 Szymon Nowak 提交于
-
- 09 1月, 2011 8 次提交
-
-
由 Mr.doob 提交于
-
由 alteredq 提交于
-
由 astrodud 提交于
-
由 alteredq 提交于
Also some refactoring of initWebGLObjects slipped in this commit.
-
由 astrodud 提交于
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-
由 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 3 次提交
-
-
由 astrodud 提交于
added LathedObject which creates a geometry by rotating a set of Vertices around the z axis. UV mapping is supported. See http://astrodud.isgreat.org/asteroids for an example.
-
由 alteredq 提交于
-
由 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).
-
- 07 1月, 2011 1 次提交
-
-
由 alteredq 提交于
Unfortunately performance issues are still there and now already trickled down also to dev channel :( I wonder what they did - fps numbers look more or less ok, problem is more with subtle yet very annoying choppiness. Like if somewhere suddenly bandwidth / memory is getting trashed.
-
- 06 1月, 2011 3 次提交
-
-
由 alteredq 提交于
-
由 alteredq 提交于
Also first time I noticed issues with stats widget in latest Chrome canary 10.0.624.0 / Chromium continuous build 10.0.629.0: - it doesn't show in demos with mixed canvas / WebGL content (OBJ converter demo, lights test) - simply just adding it can significantly decrease performance (OBJ converter demo is choppy when invisible stats element exists) - in some demos it has different transparency (Walt cubemap demo) Looks like with some Chrome update in last few days we hit some new compositing or 2d canvas issue (both OpenGL and ANGLE versions share the same issues).
-
由 Alex Schworer 提交于
-
- 04 1月, 2011 5 次提交
-
-
由 alteredq 提交于
Texture wrapping had to be "repeat".
-
由 alteredq 提交于
Still some bug with textured one :(
-
由 alteredq 提交于
-
由 alteredq 提交于
-
由 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)
-