• Content Count

  • Joined

  • Last visited

  • Days Won


binki last won the day on February 6 2017

binki had the most liked content!


About binki

  • Rank

Contact Methods

  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As a followup, wondering if the extensions can be included in the npm package for babylonjs. It’d be nice to be able to do a deep require like require('babylonjs/extensions/materialsLibrary/water'). And putting the .fx files in there would probably make sense. I would have to figure out how to get my webpack setup to work with shaders, yet to do that. But if the files could at least be in the npm package so that I can access them at all, it would make my webpack project much easier. Thoughts?
  2. If I look at and inside the provided babylonjs-2.5.0 npm package, I observe that I have no way to access the Canvas2D project’s API. I think the babylonjs npm user should publish a Canvas2D package so that we can use it in webpack projects and I think this should be published by the official babylonjs npm user. Thanks!
  3. Thanks for the comments. I still find it confusing that I have to choose one of the meshes to be the parent just to get a compound impostor. Is there a non-mesh grouping object I could use as the parent instead of a mesh with an impostor attached? Also, it is confusing that the parenting system requires an exact sequence in setting the physicsImpostor on the parent and child (i.e., child must be set first). Shouldn’t it not matter and you be able to recompose arbitrary groups of meshes into/out of compound impostor groupings? The parent/child of BabylonJS without physics is a lot less constrained than when using physics. But if you start using impostors and expecting things to work when you parent things, suddenly you have to follow rules such as the sequence you set impostors. It seems like the type system/API makes it easy to do things that won’t work with the new way ;-). Maybe some of these issues could be resolved with documentation updates.
  4. Oh, my updated playground:
  5. Oh, seems like the code requires you to write to `AbstractMesh.physicsImpostor` because it just does. If it is really required to write to `AbstractMesh.physicsImpostor`, why doesn’t `new PhysicsImpostor()` just do that for you? It’s sort of confusing in the same way that requiring you to call `PhysicsImpostor.forceUpdate()` is. Another question: why does making a compound impostor require this parent-child relationship? Shouldn’t all of the impostors be siblings instead of arbitrarily choosing one as the parent? I can sort of see that there should be a parent (as the compound impostor thing sort of eats the child impostors), but it seems weird that one of the child Mesh object has to be the root of the compound grouping. Is there a way to group the spheres without any of them being the parent and using some non-Mesh grouping thing (or something like `AbstractMesh` as a grouping thing?) to group them together in a more logical way? Is there a way to set a mesh’s parent without having to remember things like “I need to call `parent.physicsImpostor.forceUpdate()` whenver I do this”?
  6. FWIW, here’s my attempt at unrolling the code from createCompoundImpostor: But as you can see, the sphereChild doesn’t collide with the ground like I expect it to.
  7. When I look at the docs for [Scene.createCompoundImpostor](, it says that it’s deprecated without any explanation about what I should be using instead. [in the source]( I see the same thing—a mark of deprecation with no explanation. Is there an example of how to create compound impostors? E.g., can I get two or more spheres to be tied together as if there were such a thing as a rigid joint constraint without using the deprecated function or physicsBody hacks?