• Content Count

  • Joined

  • Last visited

Posts posted by digitspro

  1. 4 hours ago, Deltakosh said:



    intersectsMesh does not take in account any scene or visual parameters. It just checks if two meshes intersect.


    Thanks for the reply. Fair enough, but even with this consideration, intersectsMesh is not behaving as expected;

    In this case, I would not expect intersectsMesh result to be affected by changing setEnabled flag. If you notice this is what is happening now:

    1) I have two meshes enabled. No overlapping. intersectsMesh gives false.

    2) I disable one of them. Nothing else is different. Position etc are same.

    3) intersectsMesh suddenly gives true.

    I can do checking on my end to avoid this undesired behaviour of course, but I prefer to bring it up if it is really a bug as I thought. It is surely strange to me. Following what you said, one would not expect its output to change at least in this scenario.

  2. Hi,

    Why is it that when I have a mesh disabled (i.e. mesh.setEnabled(false)) any intersectsMesh by it or against it returns true? Setting the method's second parameter 'precise' to true does not help.

    This output seems counter intuitive and I do not believe it is what anyone would expect. In fact, my intuitive expectation is that by having the mesh disabled, any intersectsMesh on it or against it should return false (even if the mesh being tested with it is in the same position that it would appear in if enabled).

    What do you think?


    Playground showing the problem (watch out for the browser console which prints the result of the intersectsMesh method testing two exclusive spheres in position which one of them is disabled): http://www.babylonjs-playground.com/#PD7PP#0

  3. Hi there,

    I have a minimap implemented by having a secondary camera in a RenderTargetTexture applied on a plane. In the 2.6 preview version since a change committed on Dec 21st 2016, something has been broken. So when I dispose an object in my scene, the entire plane which holds the minimap (the RenderTargetTexture of a camera) disappears too. This is obviously not the expected behaviour.
    I traced the problematic commits and they happened to be these:

    commit 49e419016287753a9720a46114bbc605df69db79
    Merge: 55f1083 d0fbbc9
    Author: David Catuhe <david.catuhe@live.fr>
    Date:   Wed Dec 21 12:23:33 2016 -0800
        Merge pull request #1622 from haxiomic/UseOpenGLProjectionMatricies
        Use OpenGL projection matricies over Direct3D for better depth precision

    To reproduce the problem, please download the attached zip and run index.html. The code has setTimeout that will dispose the sphere. You will see that the minimap disappears too. Then when you modify index.html to reference good-babylon.js instead of bad-babylon.js you will see that when the sphere disappears, the minimap will not disappear. bad-babylon.js is the current preview version built from master, whereas good-babylon.js is from a version before the problematic commit.


    I hope someone knowledgeable of the changed area of code fix the issue for us.


  4. 41 minutes ago, Codeaddictx said:

    Thats exactly what I am doing. There is a central login point where coordinates are emitted to all clients. But some funny reasons I can't explain they won't just align. A simple test was to move one of the players  directly over the other and left it there. It appears so on the first screen, but on the second, it was few pixels away from it.

    hey man. I'm soon going to start diving into multiplayer implementation like you. I have zero experience in that. I think you need to double check few things:

    1) How you are reading the positions: position property, getAbsolutePosition(), scene.pick() data, window mouse event etc

    2) When you are transmitting the data and whether the last coordinates you expect did really get received by the other client, and that they are really the last

    3) How you are setting the positions: position property, etc.

    I do not have much information, nonetheless this is general guideline of what I would investigate on.

    I'm thinking, it would be useful to mock the events received from the server, like put them in a file and have that file be read line by line. Then I would be able to test the receiving client in isolation...

    UPDATE: just a little more clarification:

    Clearly, using coordinates reported by objects of the game engine is the right thing to do, because that's what's expected to remain consistent, unlike screen resolution, render width or mouse location on window.

  5. Hey @Wingnut I'm glad you came by my friend. Your playground of rendering camera views on plane is brilliant work! And it is the only solution for me to achieve minimap transparency. After playing in your playground I found out that by simply setting alpha on the plane material whose texture is the minimap camera view, then we achieve transparency. It was really smart how you then positioned that plane relative to the active camera by setting the parent of the plane to be the camera, then we always have minimap (plane) in relative position as if it is overlayed in the projection world! Ah so goooood! *claps*

    Here is a solution from my first post's playground to see where the additional work fits. For our future readers pleasure:



    Marking post as RESOLVED


  6. I notice that all the stuff covered in https://doc.babylonjs.com/tutorials/Using_the_Canvas2D are gone in the current preview version 2.5-beta. I am worried to go the direction of using Canvas2D stuff if it is deprecated, as it will hinder me from future upgrading to the latest of babylonjs :( 

    False info. It was an issue with Visual Studio that made me think all these classes are gone. I had to open the d.ts files for V.S. to know these definitions exist

  7. Hi there,

    Just a short intro, big fan of BabylonJS library! It got me excited to work on a new project of mine which is my first game. Bear with me now please, as I am fairly new to it, although I'd say I have done my studies on your API and documentation, which looks very attractive.

    The issue I am having is that when I scale objects bigger, collision goes wrong; Moving objects collide when they have already overlapped. What I expect is that the collision happens as soon as any face of a bounding box touches any face of the other bounding box

    The more I scale my objects, the worse things look.

    Please take a look at this playground which is hopefully self explanatory:


    Further worse, uncomment line 29 which scales the ball bigger and see the obvious overlap with the wall.

    I messed with the methods and properties in the BoundingInfo but nothing helped. It does not look to me that the BoundingInfo is missing something anyway; as you can see, showBoundingBox = true (i.e. the wireframe) reveals nothing unexpected to my eyes. It's the whatever shape/thing that is used to calculate collision is what seems wrong and does not seem to update with the scaled ball. Shouldn't it?