• Content Count

  • Joined

  • Last visited

  • Days Won


Feldspar last won the day on June 11 2014

Feldspar had the most liked content!

1 Follower

About Feldspar

  • Rank
    Advanced Member
  • Birthday 09/08/1989

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location
  • Interests
    Girls, drugs, money and WebGL

Recent Profile Visitors

1129 profile views
  1. PR has been merged, so I suggest that you use 3.2.0-alpha4 that contains the fix. Cheers,
  2. Hey @BlackMojito, bug will be fixed with that PR : https://github.com/BabylonJS/Babylon.js/pull/3546. Until it's merged and in the latest release, you can fix it by applying minor changes in the SSAO2 shader, see the diff. Cheers,
  3. We are indeed far better No more intensive CPU usage because of getters and GC. I also took the initiative of replacing disableLighting and cameraColorCurves by their respective private properties _disableLighting and _cameraColorCurves. Thanks for you help, I'll keep you updated of the following implementation of UBO for materials.
  4. Hello @Deltakosh, I'm currently working on implementing UBO (uniform buffer objects), and i merged the most recent changes about StandardMaterial becoming a PushMaterial. Everything is now working fine, but I'm encountering performance issues against the unmerged version. My focus currently goes onto frozen materials, since they are the most optimized way to use UBO : 1 uniform buffer per material, which is static. I've tested with a simple scene with 1600 visible spheres, each one having a different material, lit by a moving HemiLight, here are the results : UNMERGED (StandardMaterial is still NOT a PushMaterial), with FROZEN materials : MERGED (StandardMaterial IS a PushMaterial), with FROZEN materials : MERGED (StandardMaterial IS a PushMaterial), with UNFROZEN materials : As you can see on profiles, a lot of time is spent on getter functions, most likely because they contain get: function () { return this["_" + key]; }, which is really slow in JS. So my question is : do you have any idea on how to prevent that slow-down to happen on frozen materials ? Maybe i am missing something in my UBO implementation code to deal with that ? Btw, It's really likely that unfrozen material spend less time in "isReady" functions, so are still more optimized despite the heavy "get" functions. Thanks for your kind advices
  5. @sebavan, found my bug. You were right the canvas didn't have a stencil buffer, but failed silently. Indeed, i used getContext("webgl") (without stencil) once to test if WebGL was available, then Babylon's call to getContext somehow reuses the context already fetched, even though you give it { stencil : true }. Sneaky bug Thanks !
  6. Hello, I have a strange effect using the outline on my meshes. Seems like some stencil issue, any idea ? EDIT : the demo is working fine, and canvas has stencil buffer activated (and no warning/errors in the console). The code : var mesh = BABYLON.Mesh.CreateBox("object", 30, scene); mesh.material = new BABYLON.StandardMaterial("mat", scene); mesh.material.diffuseColor = new BABYLON.Color3(1.0, 0.0, 0.0); var hl = new BABYLON.HighlightLayer("hg", scene); hl.addMesh(mesh, BABYLON.Color3.Green()); Cheers,
  7. Hi guys, We just released today our new version of Wanaplan : www.wanaplan.com This is a 3D home planner that was originally built with Three.js, but we decided a while ago to use Babylon instead, and it works fine now, even better We tweaked the engine a little bit to be case-specific, so the renderings are way faster when the number of objects grows (still CPU limited though). Check it out ! (also available on the french website www.kozikaza.com) If you see some features you're interested in, and you'd like to implement them in your own project or in babylon.js itself, just give me a heads up. Cheers, Feldspar
  8. I agree with demonixis, for each texture you have on your material, there is only 1 more boolean to test. The best part is, since JavaScript has lazy evaluation on booleans, whenever you have this.ambientTexture && BABYLON.StandardMaterial.AmbientTextureEnabledIf this.ambientTexture === undefined, the evaluation will stop here and BABYLON.StandardMaterial.AmbientTextureEnabled will not even be tested.
  9. Concerning sprite picking, what I did - awaiting for a better solution - is creating a simple invisible plane which always face towards the camera, and which size and position match the sprite's one. Then I just use this invisible plane for picking the collision with the sprite. It's kinda ugly but it works very well
  10. I agree with that, but what if you move the child on frame 200 without moving the parent ? Every render loop will then force update the children since 200 != 100 then 201 != 100 then 202 != 100 etc....
  11. I may be wrong but I still see a problem with your patch. Say we update the parent on frame 100, parent._currentRenderId will be set to 100. Then we move the child on frame 200, this._currentRenderId will be set to 200. Now, in all the subsequent render frames, BABYLON.Node.isSynchronizedWithParent will return false, and the child will be force updated in every frame, setting its _currentRenderId to 201, 202, 203, etc.. That was why I suggested : return this.parent ? this.parent._currentRenderId <= this._currentRenderId : true;- If the parent _currentRenderId is strictly greater than its children, then the children MUST be updated to move along with the parent. - But if the parent _currentRenderId is lower the child's _currentRenderId, it just means that the parent has not moved for a certain amount of frames, the synchronization is fine
  12. I suggest this patch : in BABYLON.Mesh.computeWorldMatrix : if (!force && (this._currentRenderId == this._scene.getRenderId() || this.isSynchronized(true))) { return this._worldMatrix; } this._currentRenderId = this._scene.getRenderId();And in BABYLON.Node.isSynchronizedWithParent : return this.parent ? this.parent._currentRenderId <= this._currentRenderId : true;
  13. Yes sure but, in computeWorldMatrix, which is called every frame for every mesh, you have this chunk of code : if (!force && (this._currentRenderId == this._scene.getRenderId() || this.isSynchronized(true))) { this._currentRenderId = this._scene.getRenderId(); return this._worldMatrix; }This implies, even if the parent hasn't moved, its _currentRenderId will always match the current frame's render id, so the children will be forced to recompute their worldMatrix/bounding box even if they haven't moved either (since this.isSynchronized will be false if they are updated after their parent). Am I right on this, or am I missing something ?