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.
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.
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).
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)
loader.loadAscii and loader.loadBinary now take just one parameter with following properties:
- model (required)
- callback (required)
- texture_path (optional: if not specified, textures will be assumed to be in the same folder as JS model file)
- bin_path (optional: if not specified, binary file will be assumed to be in the same folder as JS model file)
Example use:
loader.loadBinary( { model: "model.js", bin_path: "path/bin", texture_path: "path/img",
callback: function( geometry ) { createScene( geometry ) } } );
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.
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.
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.
Mr.doob
alteredq
astrodud
Mr.doob
Alex Schworer
Szymon Nowak