10

Following up on my earlier question about finding the slope of a 2D bitmap terrain I now need to know the best way of finding the point on the 2D terrain that the missile hit. Obviously, I can see if any pixels under the missile intersect terrain, but say it has moved quite deep into the terrain.

What is the best way to step back to find where it initially collided? I could move back X pixels at a time towards the missile's previous position, but what would be a good value of X? And is there a smarter way? Maybe moving half the distance, then a quarter etc?

Community
  • 1
Iain
  • 6,518
  • 3
  • 33
  • 46
  • The phenomenon you're describing is commonly called "tunneling", and the best way to deal with it is to introduce a sweep test - as TetraD and JasonD have both mentioned below. – jpaver Aug 18 '10 at 21:19
  • just saying "sweep test" doesn't actually help me though. How do I do it with a bitmap terrain? – Iain Aug 19 '10 at 10:20
  • Jason's suggestion seems to be best to me: one pixel at a time. – jpaver Aug 19 '10 at 15:51

4 Answers4

3

For collision testing you shouldn't do tick-by-tick static testing, you should be doing traces/sweep tests.

There's an exhaustive list of various formulas for different kinds of primitives here: http://www.realtimerendering.com/intersections.html

That is, of course, assuming you can break down your terrain into some kind of set of primitives you can test against (i.e. line segments). There are various ways of doing that.

See also this question (only slightly related): What is a good algorithm to detect collision between moving spheres?

Community
  • 1
Tetrad
  • 30,124
  • 12
  • 94
  • 143
  • I was thinking about a destructible bitmaps terrain like in Worms. Could you dynamically generate primitives from a bitmap or would that be too crazy? – Iain Aug 19 '10 at 08:30
  • 1
    I'm sure you could, but it might be easier/faster just to do pixel by pixel testing for an arbitrary bitmap. – Tetrad Aug 19 '10 at 16:37
  • WITH A QUADTREE!! (so it doesn't take forever) – bobobobo Nov 27 '11 at 01:02
3

Binary search wont help if you have thin bits of scenery and fast moving projectiles - you might miss them.

I think your best option is to sweep a line across the front of the projectile along the path it takes, pixel at a time. You could do a bounding check first on the whole volume to avoid doing it every step.

JasonD
  • 2,949
  • 1
  • 21
  • 17
  • What's binary search? – Iain Aug 18 '10 at 21:16
  • 1
    Sorry - binary search is more or less what you were talking about in the question. You start in the middle, and divide the search space by two until you converge on the answer. It's optimal in many cases, but in your case it would not work (you might skip the correct answer entirely). – JasonD Aug 18 '10 at 21:35
3

Since the missile is unlikely to move a huge amount of pixels each frame (it wouldn't be smooth on screen) I see no reason to not just check every pixel on the path. Bressenham line algorithm is your friend, and making sure you got a local copy of your bitmap too as you generally don't want to access video memory for every pixel. This is assuming your bitmap terrain is fully random (as per destructable worms terrain). If your world is tile based you could skip every tile that you know is empty to begin with, but as mentioned before, unless you have a huge amount of missiles to check I couldn't think of a platform that would need that is too slow to just test pixel by pixel, and you won't need to have your world defined in primitives (a worms clone would make that tricky)

Kaj
  • 3,246
  • 21
  • 18
  • yeah I was thinking a Worms-like terrain. Could you divide it in to tiles dynamically, then just mark empty tiles to not be checked? If there were a lot of missiles at once maybe that would speed things up a bit? – Iain Aug 19 '10 at 08:28
  • So do you think I shoudld move forward pixel by pixel, checking intersection, rather than stepping backwards? – Iain Aug 19 '10 at 08:49
  • I think all three answers have suggested a forward search. Checking backwards isn't going to work if the forward step makes it skip over some scenery. – JasonD Aug 19 '10 at 09:07
  • Yes, definitely forwards. – Kaj Aug 19 '10 at 15:03
1

In addition to the other answers, there are some things you can do to speed this up if you want to do a little bookkeeping with regards to "collecting" a bunch of pixels into blocks of "known similar state." E.g. you could store the height of the highest terrain piece, so you can take for granted that the missile won't hit anything as long as it's above that. You could also store the height of the lowest "air" space, so you'll know that if the missile gets to that altitude that it must have hit something (although this might be best used as a sanity check). Going further than this, you could store rectangles representing areas that are all terrain and other rectangles that are all air, but that might be more work than value.

Ultimately, the best method is probably going to be "store off the height of each terrain column" and then just compute the missile height at each step of its path. I can't speak to more modern games, but I believe that when you made a "cave" in Scorched Earth, that the terrain above that cave fell straight down, leaving no overhangs. If you want overhangs the work will be a little greater, but it will be an extension of this basic idea. (Hint: get the basic idea working first!)

Since your terrain is presumably completely arbitrary, there are no shortcuts. Even if you forced your terrain to be a spline or something, that'll get upset once you start destroying it and line-spline intersection tests are iterative and non-perfect or exhaustive and pointlessly slow for your type of problem.

dash-tom-bang
  • 1,666
  • 9
  • 11