Jump to content

Sprites are (sometimes) passing through polygon barrier


ContrivedExample
 Share

Recommended Posts

My sprites are often passing through polygons that they should be bouncing off of. I've tried to research this and all I could find is that the fps may be too low to always detect the collision but surely the game engine should be able to handle this?

Interestingly, if I use setCircle() my colliding sprites never pass through even with much higher velocity. Why would a polygon I define behave differently than setCircle() ?

Here is a demonstration:

//phaser.io/sandbox/xeGQxHis

Link to comment
Share on other sites

Objects moving "fast" relative to their "size" are likely to pass through each other, depending on update time, as you already found out. This is the tunnelling effect. The answer to tunnelling is CCD, continuous collision detection, usually with swept-shapes or swept-volumes. As far as I know this is not supported in all, if any, physics engines in Phaser (arcade vs box2d vs ninja ; to be confirmed ?) as it quickly becomes very computational and intensive ; the idea usually works well at reasonable cost for simple primitives (a point swept over time becomes a ray, a sphere swept over time becomes a capsule, etc.) but is almost impossible to do with arbitrary polygons, shapes, volumes and meshes (a swept random mesh becomes... an even more complex random mesh !). That's the reason collision groups in games are usually a hierarchy of primitives, rather than custom shapes.

Btw, is your custom collision polygon closed and convex ? This makes things a lot easier in terms of computations, accuracy, etc. And primitives like spheres, cylinders, etc. are even easier as it's possible to use implicit solvers, rather than discrete edges.

My general advice would be to ban custom hitcheck wherever possible and approximate complex shapes with hierarchies of physics primitives, especially for animated elements.

Link to comment
Share on other sites

1 hour ago, Refeuh said:

Objects moving "fast" relative to their "size" are likely to pass through each other, depending on update time, as you already found out. This is the tunnelling effect. The answer to tunnelling is CCD, continuous collision detection, usually with swept-shapes or swept-volumes. As far as I know this is not supported in all, if any, physics engines in Phaser (arcade vs box2d vs ninja ; to be confirmed ?) as it quickly becomes very computational and intensive ; the idea usually works well at reasonable cost for simple primitives (a point swept over time becomes a ray, a sphere swept over time becomes a capsule, etc.) but is almost impossible to do with arbitrary polygons, shapes, volumes and meshes (a swept random mesh becomes... an even more complex random mesh !). That's the reason collision groups in games are usually a hierarchy of primitives, rather than custom shapes.

Btw, is your custom collision polygon closed and convex ? This makes things a lot easier in terms of computations, accuracy, etc. And primitives like spheres, cylinders, etc. are even easier as it's possible to use implicit solvers, rather than discrete edges.

My general advice would be to ban custom hitcheck wherever possible and approximate complex shapes with hierarchies of physics primitives, especially for animated elements.

Thanks Refeuh, I don't know if my shape is convex but when I was experimenting I tried using several polygons and I got an error that convex shapes had to be counter-clockwise (or something like that) so I reversed the order of the points and stopped getting the error. Since I don't get that error with this shape I assume it is convex. I aslso assume it is closed. I don't know if you had a look at the example on phaser sandbox but you can see the polygon in debug mode.

There must be something wrong with my shape, however, because I tried using the PysicsEngine tool to generate it and it works perfectly. I never get a pass-through. I noticed the generated shape is actually many shapes, not just a singe polygon so there is something about shapes that is important but I don't understand what. Do you think that it is just that the generated shapes are constrained to "simple primitives".

Link to comment
Share on other sites

'Not sure what "PhysicsEngine tool" you are referring to, but do you have a screenshot of the output ? It would be interesting to compare to your manually defined shape ! It could indeed be constrained to convex polygons or primitives, as you're suggesting, since these are easier to deal with for collisions at runtime ; thus providing better accuracy and eliminating your issues and collision artifacts.

Link to comment
Share on other sites

24 minutes ago, Refeuh said:

'Not sure what "PhysicsEngine tool" you are referring to, but do you have a screenshot of the output ? It would be interesting to compare to your manually defined shape ! It could indeed be constrained to convex polygons or primitives, as you're suggesting, since these are easier to deal with for collisions at runtime ; thus providing better accuracy and eliminating your issues and collision artifacts.

Yeah, I will update my sample and post the generated shape(s) as soon as I can. This is the tool that generates the "good" shapes: https://www.codeandweb.com/physicseditor

When I created my own I just went around the sprite in an image editor and noted the x,y coordinates.

Link to comment
Share on other sites

Just now, ContrivedExample said:

No, I just think I created a "bad" shape because I don't yet understand how it really works.

That's nonsense. You can't create a bad shape. Collision detection is very simple. When it fails, it's tunneling. And that means too few steps. So either use CCD, or just keap increasing the steps.

Link to comment
Share on other sites

1 minute ago, Milton said:

That's nonsense. You can't create a bad shape. Collision detection is very simple. When it fails, it's tunneling. And that means too few steps. So either use CCD, or just keap increasing the steps.

So how do you explain the fact that I have no problem when I use the polygons created by Physics Editor (https://www.codeandweb.com/physicseditor) ? Additionally, HTML game development would be pretty useless if it could not handle the simple game I have posted in the phaser sandbox.

Link to comment
Share on other sites

1 minute ago, ContrivedExample said:

So how do you explain the fact that I have no problem when I use the polygons created by Physics Editor (https://www.codeandweb.com/physicseditor) ? Additionally, HTML game development would be pretty useless if it could not handle the simple game I have posted in the phaser sandbox.

If you have CCD (infinite steps) you'll get your collision. Maybe the PE shape just collides easy, who knows. Did you at least try playing around with frameRate and useElapsedTime?

Link to comment
Share on other sites

4 minutes ago, Milton said:

If you have CCD (infinite steps) you'll get your collision. Maybe the PE shape just collides easy, who knows. Did you at least try playing around with frameRate and useElapsedTime?

No have not, but I will to see what effect it has - after I figure out what you are talking about. I'm a developer but not a game developer so I don't yet even know what CCD is or how to change it.

I have updated the sample, you can see how the Physics Engine generate shapes look and act:

http://phaser.io/sandbox/xeGQxHis

Link to comment
Share on other sites

53 minutes ago, Refeuh said:

'Not sure what "PhysicsEngine tool" you are referring to, but do you have a screenshot of the output ? It would be interesting to compare to your manually defined shape ! It could indeed be constrained to convex polygons or primitives, as you're suggesting, since these are easier to deal with for collisions at runtime ; thus providing better accuracy and eliminating your issues and collision artifacts.

I have updated the sample, you can see how the Physics Engine generate shapes look and act:

http://phaser.io/sandbox/xeGQxHis

For reference, here is my shape (thickspinner) and the generated shape (donut):

 {
    "shape": [ 97, 106, 110, 92, 117, 75, 119, 52, 111, 29, 100, 15, 83, 4, 58, 1, 30, 7, 13, 22, 3, 39, 0, 58, 4, 81, 11, 94, 22, 106, 38, 78, 33, 69, 32, 58, 34, 48, 40, 39, 49, 34, 59, 31, 71, 33, 78, 39, 85, 48, 88, 59, 86, 69, 81, 77 ]
  }
],
"donut": [
  {
    "shape": [ 83, 76, 105, 102, 97, 107, 81, 80, 81, 77 ]
  },
  {
    "shape": [ 39, 80, 37, 76, 39, 77 ]
  },
  {
    "shape": [ 97, 107, 105, 102, 101, 106 ]
  },
  {
    "shape": [ 42, 39, 3, 38, 48, 35, 47, 37 ]
  },
  {
    "shape": [ 113, 91, 105, 100, 87, 54, 108, 24, 117, 38, 120, 49, 120, 71 ]
  },
  {
    "shape": [ 0, 49, 3, 38, 37, 76, 39, 80, 23, 107, 19, 106, 7, 91, 0, 71 ]
  },
  {
    "shape": [ 28, 8, 38, 3, 49, 0, 71, 0, 108, 22, 54, 33, 3, 38, 12, 22 ]
  },
  {
    "shape": [ 87, 67, 105, 102, 83, 76 ]
  },
  {
    "shape": [ 108, 22, 71, 0, 82, 3, 94, 9 ]
  },
  {
    "shape": [ 87, 54, 105, 100, 105, 102, 87, 67 ]
  },
  {
    "shape": [ 117, 38, 108, 24, 112, 28 ]
  },
  {
    "shape": [ 3, 38, 33, 67, 37, 76 ]
  },
  {
    "shape": [ 3, 38, 33, 54, 33, 67 ]
  },
  {
    "shape": [ 3, 38, 35, 48, 33, 54 ]
  },
  {
    "shape": [ 3, 38, 42, 39, 35, 48 ]
  },
  {
    "shape": [ 3, 38, 54, 33, 48, 35 ]
  },
  {
    "shape": [ 108, 22, 66, 33, 54, 33 ]
  },
  {
    "shape": [ 108, 22, 78, 39, 66, 33 ]
  },
  {
    "shape": [ 108, 22, 85, 48, 78, 39 ]
  },
  {
    "shape": [ 108, 22, 108, 24, 87, 54, 85, 48 ]
  }
]
Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...