Path: chuka.playstation.co.uk!toby From: toby@angst.forefront.com.au (Toby Sargeant) Newsgroups: scee.yaroze.freetalk.english Subject: Re: Collision Detection Shortcut Update Date: 17 Feb 1998 22:19:33 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 65 Message-ID: References: <6caa8e$5bj12@scea> <34E97C6B.646B@manc.u-net.com> <34E990B1.7CE@mdx.ac.uk> NNTP-Posting-Host: ns.forefront.com.au X-Newsreader: slrn (0.9.4.6 UNIX) On Tue, 17 Feb 1998 13:29:21 +0000, Robert Swan wrote: >James Shaughnessy wrote: >> 2) I suspect that collision in 3D fighters is a LOT simpler than >> using a load of collision spheres all over them -- that would be >> too expensive I'd say. The way I would do it is just use simple >> logic tests based on what move one character is doing, with what the >> other character is doing and their distance apart (they are always >> either looking at each other or away (and moves are limited) so you >> can think of collisions in a simple 2D form.) Then all you do is >> match the variables with what each character's body is like (height / >> arm reach etc.) so it appears as though when a hit a takes place it was >> due to the hand literally touching the face in 3 dimensions. Which is >> nice. > >I think that is correct about 3D fighting games. I remember back when >they were converting Virtua Fighter to the Saturn, they released a >demo with only two moveable characters, but they said they had yet to >implement the collision/move tables, suggesting that all contact >permutations are precalculated and then its just a simple logic >test. Having said that, in these days with such complex movements >possible, calculating these tables beforehand would be a huge >numbercrunching task, compared to simpler, more general routine of >testing bounding volume intersections (even though this is much >slower in execution) I'd be VERY impressed for a home developer to >attempt this :) >Robert Swan >rs108@mdx.ac.uk >http://www.netyaroze-europe.com/~middex2 Well, in the simple case, which a lot of 3d fighters adhere to, the two characters only exist in a 2 dimensional plane. Hence, for any particular move (and any particular block), you only need to calculate the positions at which a collision occurs, and store that. In all likelihood, these regions can then approximated by a (list of) geometric shape(s), so the algorithm becomes simply: if fighterA attacking: attack=unsucessful c=collision table for moveA,moveB for region in c: if centre(fighterA) in region attack=sucessful This sort of matches the near-enough-is-good-enough feel that most games seem to have. More complex moves are generally of the multipl attack type, which just requires that the test is performed a number of times during the move with slightly different collision tables, or are things like throws which can be implemented using the same algorithm, and only continuing the throw if the 'hit' is successful. Extending this to 3 dimensions is difficult, because suddenly you've got to consider the directions that each character is facing. In this case, you could probably use a bounding sphere for the hit surface, and some kind of simplified mesh over the target body to test against. People will get very confused if your collision detection algorithm is too accurate, so the correct 'feel' is just as important as the speed of the algorithm. Also, because movements are generally triggered only a few times a second, and exist over several frames, the collision detection can be reasonably complex, because it has a long time to execute. The physics in racing games is much more likely to be a hard problem. Toby.