Hi community,
I’m wondering what I’m doing wrong that the collisions aren’t detected: https://www.babylonjs-playground.com/#4VM49Q#3
If you swap BABYLON.Mesh.CreateGroundFromHeightMap with BABYLON.Mesh.CreateGround (starting at line 28) it works as expected.
any help appreciated!
Regards
It works perfectly well for me on your PG. I’m using Google Chrome
Of course the sphere collides/bounces off with the ground as expected. The problem is, that sphere.physicsImpostor.registerOnPhysicsCollide(ground.physicsImpostor, myCollide); isn’t called which should change the sphere’s color. This doesn’t seem to work.
Hi guys. I did some tests.
The 4VM49Q playground series (which Holger shows us)… is essentially a clone of https://www.babylonjs-playground.com/#1IB3JT#7… which works.
In the ABOVE playground (#7), change line 39 from BoxImpostor… to HeightmapImpostor. Run. Still works fine, right?
What does THAT tell us? I dunno. It seems… HeightmapImpostor triggers collides FINE… unless the heightMap has elevation/bumps (officially called ‘displacement’, I suppose).
My thoughts… maybe the ball-bounce would trigger onCollide if the heightMap were inverted… and maybe baked into that orientation.
https://www.babylonjs-playground.com/#1IB3JT#9 Don’t do it, guys… baked-in rotations or not. Turn on the ground’s physicsImpostor at lines 53-56… AT YOUR OWN RISK! heh. Console spews a “plethora” of errors… quite a pretty report about faces and normals and all sorts of transgressions. 
Clear it off your console quickly, or it will bog your hog.
Good fun.
All in all, it seems heightmaps and heightmapImpostor is fine… unless it has displacement. One might want to try growing their heightmap from a perfectly black (perfectly white?) heightmap-displacer file… see what happens. (an absolutely-no-height heightmap). shrug.
You should add the onCollide function only after the ground collider was initialized. otherwise it is undefined, and no collision is detected.
here:
https://www.babylonjs-playground.com/#4VM49Q#6
Thanks for all the help and answers!
@RaananW: this did the trick
One further question: What is the benefit of having collisions reported by the PhysicsEngine in contrast to BJS collision with intersectMesh
Regards
it depends on whether you want the physics collision or mesh intersection. the physics collisionos are already calculated using the physics engine (if enabled). IntersectsMesh is more for scenes without physics, as it requires further calculation (similar to what the physics engine is doing).
Ok, then I’ll go for physics collision given the fact my project already relies on it. Thanks
Thx for the help, @RaananW . Yep, we had to wait for the heightMap to finish loading, then do:
sphere.physicsImpostor.registerOnPhysicsCollide(ground.physicsImpostor, myCollide); in line 44… during the heightMap load call-back. Right? Yeah.
Holger and others… notice how using that ‘register’ thing… requires that we tell exactly WHICH mesh collides with WHICH mesh? We needed to give it TWO specific mesh, and intersectsMesh is also that way… you’re not allowed to check THIS mesh colliding-with ANY OTHER mesh. ActionManager’s onIntersectEnterTrigger ALSO requires you to specify a specific target.
Well, for physics, there is a top secret and dangerous way to monitor for ground mesh… colliding with ANY other physics-active mesh (p-mesh). I think it is similar to the old onCollide() that doesn’t seem to work anymore.
https://www.babylonjs-playground.com/#4VM49Q#7
First, I set angular and linear damping on sphere, to make it stop rolling quickly.
10 seconds later, I add mass to the 0-mass box… which makes it shoot slightly towards camera… due to a still-unfixed anomaly in Cannon plugin setParam(). Don’t sweat it. Main thing… it starts dropping after a 10-sec delay.
The box colliding wth ground… ALSO changes the color of sphere! Cool, huh? ANY physics mesh… colliding with ground… runs your myCollide function. How?
Look at line 65 (which is where Raanan’s line 44 was located in PG #6).
ground.physicsImpostor.physicsBody._listeners.collide.push(myCollide);
You guys (using the register way) stayed-at BJS mesh.physicsImpostor level… a BJS object… and you didn’t need to go deeper into native areas.
Line 65 reaches deeper… to mesh.physicsImpostor.physicsBody level (a Cannon object)… and it calls an underscored property (for internal use only?)… and… well… it’s just a deep dive into Cannon native lands… to push your myCollide function into an array of collide-listeners.
And when I did this, I was able to accomplish a ground-collides-with-ANY-physics-mesh event trigger… not needing TWO specific collide objects. Only one… ground.
Notice the object called test that arrives in the first parameter of myCollide? It has some "stuff’ on it. I tried to query that ‘test’ object to see if I could get the name of the mesh that just collided with ground (‘box’). I couldn’t find it on the ‘test’ object, but I didn’t look real carefully.
Ok, I just wanted to show you that. Rannan didn’t mention that intersectsMesh and actionManager onIntersectEnterTrigger (and ‘register’ method)… require TWO specific mesh to check for collisions… which sucks, under certain circumstances.
I have been trying to nudge @Deltakosh into allowing actionManager onIntersectEnterTrigger the option to use ‘ANY’ as the target, but he hasn’t budged. Likely a technical or performance issue.
Ok, party on, guyz.
Hi Wingnut, thanks for digging that deep 
Sometimes (not always) it’s good to have multiple ways of doing things!