Jump to content

sable

Members
  • Content Count

    88
  • Joined

  • Last visited

Everything posted by sable

  1. Looks like lines 252 and 257 need to be adjusted to take into account sprites that have been made invisible.
  2. Hi @Varsha Kamble I became far too interested in how to go about implementing this, and ended up making an improved pg based on your one above: https://www.babylonjs-playground.com/#Q2QLYZ#4 I changed the dragging implementation to use mathematical planes as projection targets (as opposed to just mesh picking). This has the advantage of not needing the pointer to always be above a mesh when dragging, and also means that all three axis should get a nice 1:1 mouse movement to screen movement in the given axis direction. Hope the above is useful and/or interesting to someone.
  3. http://playground.babylonjs.com/#41IFI5#16 See lines 134-144. Uses two methods suggested above; modifying linkedoffsetY each frame, or using an empty mesh parented to the desired mesh. What @Gijs suggested is basically what the GUI module is doing internally anyway, so is no heavier than relying on that. Regarding linkedOffsetY calculation each frame being too heavy, you're going to run into performance issues with projecting positions to screen space each frame long before performance of such a simple calculation is a concern.
  4. I've noticed that when using an action manager with sprites, both the OnPick and OnPickUp triggers are fired twice. This can be seen in the example (here), linked to from the documentation (here). Looking at the code, this seems to because scene._initClickEvent calls it's callback twice (here and here, cb being defined here). This could be solved by checking if clickInfo.ignore is true before doing all the sprite checking, unless there is a good reason this wasn't done in the first place.
  5. sable

    Instancing bug

    Thanks. Would you be able to link me to the fix?
  6. sable

    Instancing bug

    There seems to be an issue with instances in the preview version (stable is fine). Moving an instance too far way from the camera causes the original mesh to vanish (and also sometimes causes black artifacts to appear in the scene when moving the camera). http://www.babylonjs-playground.com/#M1967L
  7. There is now also the issue that the web notification API does not work in chromium based browsers for sites with insecure origins (notification permission requests for this site are now silently denied, even if notifications for the site are explicitly allowed in browser settings). https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins https://bugs.chromium.org/p/chromium/issues/detail?id=679821
  8. You should just be able to include it, and then add the touch-action attribute to the canvas (probably touch-action="none", so that default actions aren't fired). I think the readme of the github repo is the only resource I used when I started including pep in projects.
  9. Works fine in Chrome, but the issue is present in firefox for me. I second Delta's suggestion of moving to PEP and seeing if that resolves the issue.
  10. Was a bug report for this filed? Noticed the other day that the latest (non canary) Chrome on windows 10 seems to have this issue now (I'm forcing webgl 1 as a work around for now). Edit: Perhaps it's this https://bugs.chromium.org/p/chromium/issues/detail?id=792966
  11. @Vorion Never got this to work sorry, ended up just using the standard material. Would be interested in a solution though.
  12. Based on the documentation, I'd expect that the onError callback should be called if a texture 404s. It however still calls the onSuccess callback anyway, with no indication that the image has failed to load. https://www.babylonjs-playground.com/#U35TMC
  13. Here? I don't think I know enough about the underlying webgl calls and where they may be going wrong to do a bug report justice.
  14. There appears to be something wrong in the handling of materials using diffuse colours in both FF dev edition (58.0b1) and CC (64.0.3261.0), though it seems to only affect windows (tested in windows 7 on multiple machines). http://www.babylonjs-playground.com/#LW79KW Moving across the scene, only one colour (the colour of the first mesh created that is in view) is used across all meshes. If this was only happening in one of the browsers I wouldn't be too concerned, but that it happens in both makes me a bit wary that there may be some underlying issues. Looking deeper, I think t
  15. In your init function (in the iframe, main.js) you should be able to send a message to the parent page, something like window.addEventListener("wheel", (e) => { window.parent.postMessage(e, "*"); }); and receive it there with something like this in your main page js window.addEventListener("message", (e) => { //do something with the event });
  16. Hi there. Just did a similar test to Wingy, and looks like babylon doesn't block the events, http://www.babylonjs-playground.com/#C3ZPAS. Looking at your page source, I think the issue is that the scene is embedded in an iframe. You should be able to send the event (or a message) from the iframe to the parent either via window.parent or window.Postmessage
  17. All the monaco css rules are contained in the editor.main.css file from the monaco-editor npm package.
  18. While this doesn't solve the problem with LoadFromDataString, I thought I'd mention that you can request images as blobs instead of array buffers, https://playground.babylonjs.com/#RLHD87#2, which I found in my projects to be much faster as it means that a conversion to a base64 string isn't needed .
  19. I'm getting the same issue in Chrome on a macbook pro, but works fine in ff. Works fine in everything on a Windows machine, so could be a webkit bug in macOS? Also, a local build of the playground from a week or two back works fine, so some change since then has triggered this.
  20. On an i7 3770k: Chrome 61: 8783ms for asm 8326ms for wasm FF 57 (dev edition): 7769ms for asm 7611ms for wasm The frame time (top right corner) sits at 12-13ms for wasm, but 16-17ms for asm after the test is finished.
  21. @RaananW For my use case that doesn't work, as it's not about picking a certain mesh over other meshes, but rather that I want to be able to pick the mesh by clicking anywhere in the encompassing area, even where there are holes (such as the center of a torus http://www.babylonjs-playground.com/#T1PZSJ#5)
  22. That doesn't seem to actually test using the bounding box, but rather just returns the first positive result (despite what the documentation there says. The mesh.intersects documentation for fastcheck here seems more correct).
  23. Hey Delta, thanks for your reply. I was specifically looking for a way to pick using the bounding box, as the mesh I'm wanting to pick has holes in it. I want the whole area to be pickable, and using the bounding box seemed like a good way to achieve this (while also getting a nice buffer area for the pick). Thanks for the explanation regarding local space, that does make sense.
  24. I've just been finding a way to test if the pointer intersects with a bounding box of a mesh in the scene, and have come up with http://www.babylonjs-playground.com/#T1PZSJ#3 I've a couple of questions though. First, is there a more obvious way to do this that would tie in with the action manager? Second, why is ray.intersectsBox() and similar methods dealing with mesh local space and not world space (i.e. it's internally using minimum and maximum as opposed to minimumWorld and maximumWorld). There's likely a good reason, but I couldn't find anything that even references that be
  25. I've been attempting to get instances working with shaderMaterial, but am a bit stuck. http://www.babylonjs-playground.com/#QNFL1G I think I've done all the above, except as I'm not sure how to do this.
×
×
  • Create New...