I couldn’t be more wrong!
You’re correct @Wingnut I didn’t realise but I can add a collision observable (from that code you posted)
Basically I did this mesh.onCollideObservable.add(myCollidedFunction);
In “myCollidedFunction” I set a boolean that avatar is walking on something. I unset the boolean if the avatar has taken 2 steps without collision against the ground.
Cool. What arrives in the params of the observer? (If ya don’t mind teaching us.)
In other observers, args such as (d, s) arrive at the handler. They are flexible-but-standard observer objects… each containing some useful information and notify-skipping features.
In brief, are you having any difficulty getting “What did I collide-with?” info, OzR? Teach us a bit about that. if ya want.
Have you seen any “stuck-in-collision” or “too much mesh overlap” problems… when collisions happen at high-velocity?
Hey @timetocode … nice post! You need to teach… you write excellently. (Wingy hands TTC a Level 4 Docs-Writer license and shoulder-patch)
I just needed to know when my avatar is walking on something. onCollision event will also fire if I fly into a wall or ceiling and the avatar will start to fall (thinking he’s “grounded”). I’ve had to revert back to the raycast that’s pointing down into the ground.
Unfortunately the eventData and eventState parameters for the event don’t give me direction of the collision
Collider has a .collisionFound that can be continuously polled, and a .collidedMesh property. It’s gruesome, but it might work. Likely, it will trigger with ALL collides, just like the observable.
And, you know… subtract player.position from collidedMesh.position (or is it vise-versa?), and you get a direction.
I’ve been researching this as well. I’m trying to learn how to make scalable MMORPG worlds but I’ve found nothing on the web apart from the mention of “sharding”.
I’ve ordered these from Kickstarter The Most Comprehensive Book on Multiplayer Game Development by 'No Bugs' Hare —Kickstarter Only the 1st volume has been released but there’s only a small mention of dividing large worlds into smaller worlds. Hopefully the later volumes have more specific information. I don’t want players’ movements to be broadcast to every other player if they can’t even see eachother and like you mentioned, I don’t want to bother with collision detection for faraway objects.
I’m not sure subtracting collidedMesh position and player position will give me the result I want. That will tell me the direction of the other mesh but that mesh could be rotated and have strange topology
I’m way too late to this party, but I’m facing the same issue.
Raycasting is not a good solution, because it won’t detect ground if the player is standing on a ledge. What I ended up with is having a ground collider disc, at the character’s feet. When moving, the collider’s position is set to the mesh position, then we perform mWC, and if we hit something, we’re on the ground.
Note: My character meshes don’t have checkCollisions because they have too many polys, making collision detection very slow. Instead I use low-poly cylinder collider meshes that get moved with the character mesh. It’s basically the same logic as the ground collider.