• Content count

  • Joined

  • Last visited

About focomoso

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Los Angeles, CA
  1. engine.dispose() giving error on 3.1.0

    Strange... I went to do a pr to make this change myself and the version babylonjs@3.1.0-alpha3.6 already has this in, but when I get the package with npm, it's not there...
  2. engine.dispose() giving error on 3.1.0

    I did some more digging and it seems that the framework I'm using (React) cleans up the canvas while the dispose method is being called. All we need to fix this is to add an if (this._renderingCanvas) {} around the _renderCanvas.removeEventListener calls.
  3. I updated to 3.1.0-alpha3.6 and am now getting the error: "Uncaught TypeError: Cannot read property 'removeEventListener' of null" when I call engine.dispose(). The line in question is: this._renderingCanvas.removeEventListener("focus", this._onCanvasFocus); The canvas has been disposed of elsewhere and Edit: the canvas is still defined when the dispone() is called. I need to dispose of the context because this app opens and closes the gl canvas repeatedly and will evntually give a "Too many active WebGL contexts." warning. Is there a way to dispose of the context without calling .dispose()? Or is there a way to have the .dispose() method only try to remove listeners if the canvas is still defined? Thanks
  4. Also found this: That suggests sending {preserveDrawingBuffer: true} as an option, but this isn't working either...
  5. I just want to chime in here and point out that I'm seeing the same issue. For some reason canvas.toDataURL() is returning a blank png image. @IIerpos Can you think of anything that may be causing this?
  6. I've done some digging and it seems that canvas.toDataURL() is the culprit. It's returning a blank png image. This isn't babylon.js's fault per se, but can anyone think why that might be happening? I get the same issue on chrome and firefox. Thanks
  7. Unfortunately seeing the same issue with 3.1.0-alpha3.6
  8. Rendering HTML in a Babylon scene?

    Completely off the top of my head, but you may want to look at rendering html into a canvas and then grabbing that image and applying it as a texture:
  9. It seems to work fine in the PG. Not sure what my app could be doing that's any different. Could the fact that I'm using 3.0.0 be an issue?
  10. Tools.CreateScreenshot is returning an entirely transparent image: CreateScreenshotUsingRenderTarget: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAARElEQVQoU2P8////fwYiAOMAKwwPD2cAORWEG/fuZah3dkZx9erVqxkYQ0JC/gsJCTG8e/cOw0uMjIxwsYH2DBHhzQAAK0005fzJ758AAAAASUVORK5CYII= CreateScreenshot: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAF0lEQVQoU2NkIBIwEqmOYVQh3pAiOngACmkAC5eMKzgAAAAASUVORK5CYII= Edit: I found this thread: but there seems not to be a resolution. Thanks
  11. I've looked through a couple of threads for this (some seem to be older and use a different method for taking screen shots), but haven't found a simple answer. Is there a way to anti-alias screenshots? I'm using CreateScreenshotUsingRenderTarget and have played with setting the samples to various numbers, but it doesn't seem to have any effect. Image on the left is rendered with samples = 16; on the right samples = 1. Thanks
  12. Recalculate mesh shading

    But with baking the transform, you have to rebuild the normals anyway, so you're extending the time even more. You also loose the bounding box which won't work in many cases. I agree that you shouldn't rebuild the normals every time a mesh is scaled, but there should be a simple method in the babylon core that does this correctly, regardless of the scaling on the mesh.
  13. Recalculate mesh shading

    Thanks Pryme8, but the idea here is to find a solution that doesn't require baking the transform because it takes too long and destroys the local bounding box.
  14. Recalculate mesh shading

    Here's the issue layed out as best I can. In this playground: There are 4 spheres. The underlying geometry for the one on the left is a regular sphere, so there is no scaling applied and it looks as expected. The other three are flat and have been scaled up 4x in the y to become spherical. Sphere number 2 uses VertexData.ComputeNormals to explicitly calculate the normals. I would expect this method to produce a sphere with exactly the same normals as sphere 1, but it doesn't. The normals are scaled 2x more in the y than they should be (which is why the top and bottom of the sphere look darker). With sphere number 3 I calculate the normals explicitly, but again, they seem to be over scaled in the y, this time by the square of the scale factor. With sphere number 4, I calculate the normals by hand, then apply the "descaling" and it looks as expected. The results are the same if you translate or rotate the spheres. It is only scaling that gives strange results. It's possible that there's something wrong with my normal calculations, but I've been banging my head against this for a while and it seems that the way the normals are applied to the mesh is the culprit.
  15. Recalculate mesh shading

    Because if you don't scale the normals, they are scaled "elsewhere" and are incorrect. This is the bug I've been dealing with for days now.