Designing collider for a table with a hole in it

Started by
7 comments, last by Octane_Test 6 years ago

I want the help to design the collider shape for a table. This table has a hole at its center.  The table mesh file itself has the hole. The collider design should be such way that the ball can fall into this hole.

My thoughts:

I think the concave shape collider will be appropriate as it will be exact replica of the mesh file.

I am looking for some suggestions about what collider shape will be good enough for my requirements.

Golf Course with hole:

 

5ac7553a2e007_Tablehole.png.b98855bc49e1c55be4d064bd28286520.png

Advertisement

I saw your earlier topic (https://www.gamedev.net/forums/topic/696117-collision-physics-error/?tab=comments#comment-5375676) and as no one answered, I'll try and bite in order to spur on some more ideas, I'm not terribly experienced with physics engines and have never used the one you mentioned.

  1. Your first collision proxy should 'in theory' work. However physics is prone to lots of precision issues so sometimes you need to help it along.
  2. If I was doing this (is this for a golf game? or snooker or something?) I would turn the problem on its head and detect when the ball was within the hole (use a cylinder), then turn off the collision with the surface when within, or some such similar approach. This would probably be both far more efficient and less prone to precision issues.
  3. If you can't do this, first step might be to split the scene into 5 boxes, one for the hole, and 4 for the quads around it. This (depending on the design of your physics engine) might mean your collision detection isn't dealing with a bunch of triangles when it doesn't need to, and focuses the precision issues to just the hole area.
  4. Simplify the hole in the physics rep, maybe just give it 8 sides.
8 minutes ago, lawnjelly said:

I saw your earlier topic (https://www.gamedev.net/forums/topic/696117-collision-physics-error/?tab=comments#comment-5375676) and as no one answered, I'll try and bite in order to spur on some more ideas, I'm not terribly experienced with physics engines and have never used the one you mentioned.

  1. Your first collision proxy should 'in theory' work. However physics is prone to lots of precision issues so sometimes you need to help it along.
  2. If I was doing this (is this for a golf game? or snooker or something?) I would turn the problem on its head and detect when the ball was within the hole (use a cylinder), then turn off the collision with the surface when within, or some such similar approach. This would probably be both far more efficient and less prone to precision issues.
  3. If you can't do this, first step might be to split the scene into 5 boxes, one for the hole, and 4 for the quads around it. This (depending on the design of your physics engine) might mean your collision detection isn't dealing with a bunch of triangles when it doesn't need to, and focuses the precision issues to just the hole area.
  4. Simplify the hole in the physics rep, maybe just give it 8 sides.

Thank for the reply. I liked the ideas you described in point #2 and #3. I will give it a try and see if that fixes the problem. Regarding #4, I would like to have a proper circular hole.

A couple of other points:

  • Double check that your table surface is actually flat (3d modelling programs often introduce errors due to to precision)
  • Check that you are using the correct primitive type in the physics engine. I suspect the problem is because as far as the ball is concerned, every triangle it comes to, it is colliding with the edge, without recognising it should be continuous. Sometimes physics engines have mechanisms to deal with this problem (Box2D I looked at recently had 'ghost vertices' http://www.iforce2d.net/b2dtut/ghost-vertices).

I suppose maybe a better question that might help would be, what do you need this type of collider for, and what do you need the physics to do? Many games get away with faking real physics and can do away with needing a huge complex collision detection system.

For instance like lawnjelly said, if it's for a golf game suggestion #2 would be a pretty good idea. You could also fake golfing physics by splitting the problem into a few scenarios:

  • golf ball approaches hole slowly and falls in if over the hole
  • ball goes too fast and skims over the top of hole, but slows down and changes direction if approaching the hole on the side.

If it's for something like Super Monkey Ball you might need something more precise and have to go with lawnjelly's #3 or #4.

14 hours ago, samoan62 said:

I suppose maybe a better question that might help would be, what do you need this type of collider for, and what do you need the physics to do? Many games get away with faking real physics and can do away with needing a huge complex collision detection system.

For instance like lawnjelly said, if it's for a golf game suggestion #2 would be a pretty good idea. You could also fake golfing physics by splitting the problem into a few scenarios:

  • golf ball approaches hole slowly and falls in if over the hole
  • ball goes too fast and skims over the top of hole, but slows down and changes direction if approaching the hole on the side.

If it's for something like Super Monkey Ball you might need something more precise and have to go with lawnjelly's #3 or #4.

Yes, it is a Golf game.

On 4/6/2018 at 7:31 PM, samoan62 said:

ball goes too fast and skims over the top of hole, but slows down and changes direction if approaching the hole on the side.

Thank you for the reply. Can you explain about how to handle the scenario when the ball is moving too fast over the  golf hole?

On 4/6/2018 at 6:05 PM, lawnjelly said:

A couple of other points:

  • Double check that your table surface is actually flat (3d modelling programs often introduce errors due to to precision)
  • Check that you are using the correct primitive type in the physics engine. I suspect the problem is because as far as the ball is concerned, every triangle it comes to, it is colliding with the edge, without recognising it should be continuous. Sometimes physics engines have mechanisms to deal with this problem (Box2D I looked at recently had 'ghost vertices' http://www.iforce2d.net/b2dtut/ghost-vertices).

Does the ghost vertices concept exist in 3D engines? If yes, can you please give reference of any such engine?

This topic is closed to new replies.

Advertisement