Hi,
I'm developing a golf game and was wondering what the best approach would be for triggering the sound of the ball hitting things in the world?
At the moment I've got a callback hooked up to Sphere.EventManager.InitialCollisionDetected which while it gives me a callback when the ball hits the world it seems to fire a lot as the ball rolls along the terrain. Is there a way to stop this happening or some other method I could use?
Cheers,
Tim
Triggering Sounds
Re: Triggering Sounds
The multiple initial collisions are caused by it hitting new triangles. This behavior will be changing in v0.15.0 due to the new collision system (the whole mesh is considered a single object for purposes of collision).
However, for now, you can analyze the ball's collision pair in the event handler. If the previous frame had no collision pairs that touched the mesh's triangles, and the current frame does, then an initial collision took place.
You can tell if you're hitting a specific StaticTriangleGroup by setting the tag of the StaticTriangleGroup to itself. All triangles belonging to the StaticTriangleGroup will inherit the StaticTriangleGroup's tag in their own Tag property.
Note that a collision pair existing between two entities does not directly imply that they are colliding, but rather that they could be colliding (their AABB's are overlapping). You'll need to check if the number of contacts in the contact list is nonzero to determine if a pair is colliding.
If you want, you can bypass most of that in favor of a more approximate system. Each frame, you analyze the ball's collision pairs. If any have any nonzero number of contacts, the ball is in collision. If all collision pairs have zero contacts, it is not in collision. When the ball goes from a 'not colliding' state to a 'colliding' state, you play a sound or something. This will miss some collisions (like rolling on the floor and hitting a wall), but it might be good enough.
However, for now, you can analyze the ball's collision pair in the event handler. If the previous frame had no collision pairs that touched the mesh's triangles, and the current frame does, then an initial collision took place.
You can tell if you're hitting a specific StaticTriangleGroup by setting the tag of the StaticTriangleGroup to itself. All triangles belonging to the StaticTriangleGroup will inherit the StaticTriangleGroup's tag in their own Tag property.
Note that a collision pair existing between two entities does not directly imply that they are colliding, but rather that they could be colliding (their AABB's are overlapping). You'll need to check if the number of contacts in the contact list is nonzero to determine if a pair is colliding.
If you want, you can bypass most of that in favor of a more approximate system. Each frame, you analyze the ball's collision pairs. If any have any nonzero number of contacts, the ball is in collision. If all collision pairs have zero contacts, it is not in collision. When the ball goes from a 'not colliding' state to a 'colliding' state, you play a sound or something. This will miss some collisions (like rolling on the floor and hitting a wall), but it might be good enough.
Re: Triggering Sounds
Fantastic, thanks for the information!!
I'll have a go at implementing these methods and see if I can get the results I'm after.
Cheers,
Tim
p.s. Looking forward to the next update!
I'll have a go at implementing these methods and see if I can get the results I'm after.
Cheers,
Tim
p.s. Looking forward to the next update!
-
Danthekilla
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Triggering Sounds
I like the sound of that change in 15.0 any news on how its going?
Re: Triggering Sounds
There's also another way to handle the sounds. Instead of using initial collision detected, you examine contact forces in collision pairs whenever a contact is added in general (not just the first time). The contact force (found within the contact's penetration constraint) tells you how much force it has to apply. You can compare this against some threshold for sound effects and modulate the volume using its magnitude.
The above will probably be one of the preferred approaches when v0.15.0 comes out, since the 'rolling on a floor and hitting a wall' problem will occur with initial collision detection if the floor and wall are a part of the same mesh.
It's still too far to guess a specific date, but it's progressing. The version is a little bigger than I first planned (some of the relatively minor things I wanted to push to v0.16.0 were best implemented alongside the rest of the rewrites), so at least the wait won't be for nothing.
The above will probably be one of the preferred approaches when v0.15.0 comes out, since the 'rolling on a floor and hitting a wall' problem will occur with initial collision detection if the floor and wall are a part of the same mesh.
Pretty well; the main remaining work is filling out the narrow phase collision detection system. I'm currently working through redoing and improving the general case collision system (both MPR and GJK, MPR is done). There's still quite a bit left to do after that- reintegrating and improving existing special cases, adding new ones for new meshes/compound bodies, reconnecting continuous collision detection, filling in the gaps in the overall system, and then the arduous process of actually testing and fixing it until it runs as one complete wholeany news on how its going?
It's still too far to guess a specific date, but it's progressing. The version is a little bigger than I first planned (some of the relatively minor things I wanted to push to v0.16.0 were best implemented alongside the rest of the rewrites), so at least the wait won't be for nothing.