Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


An "AABB Physics Engine"


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Pinpickle   Members   -  Reputation: 108

Like
0Likes
Like

Posted 18 January 2013 - 03:36 PM

I've been working on the physics for my 2D game and for the past two weeks it's been doing my head in. I wanted something a little more complicated than what you see in 2D platformers, but I wanted to keep the feel of them by making it far less than realistic (for example, angles are out of the question). Because of this, I don't want to just implement a more comprehensive physics engine that already exists like Box2D and just disabling rotation on every body as it has so many extras that I won't be using that will be wasting valuable processing time - this game is going to be running on mobile devices so that is quite important.

 

I call this kind of physics engine I'm trying to make an AABB physics engine, as all bodies will be rigid and rectangular in shape. I can't find any documentation on something like this anywhere. I thought that I could take the really basic platforming engine that I could make in my sleep (object has horizontal speed and vertical speed, move until it collides, stop at collision point and set either horizontal or vertical speed to 0 depending on collision), and then put in some more "real world" physics such as manipulating objects through forces rather than directly changing the speed, and implementing friction on  every body. It didn't take long for me to realise that the code was just getting messy and ugly and I needed to start that from scratch and that's sort of been me for the past week reading up as I've never delved far into the physics part of games. Problem is, most tutorials and resources deal with things that I'm not interested in, collision detection with shapes that aren't rectangles, and angles, it's frustrating.

 

So I'm looking for a starting point, or some really useful documentation, or even a physics engine like this that already exists, I'm writing this game in AS3.



Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 9289

Like
2Likes
Like

Posted 18 January 2013 - 07:20 PM

The problem is that while axis-oriented rectangles look simple from afar, their response to collisions is full of special cases. If your objects will always remain AABB's, especially if they can go in any direction at any velocity, your collision code gets quite tricky. The first step clearly is to implement collision detection and collision response.

 

The first one is rather easy and I'm sure you've already found links, but here is one. The second one is not too bad because if you model your objects as rigid, frictionless, nonrotating entities, you can apply conservation of momentum and solve for the two objects' final velocities, using the normal of the colliding side (which you can get from  collision detection). See how it is done for two spheres and you should be able to solve for the general case (hint: the reason objects identical in every way except their shape collide differently is because they have different collision normals). Implementing friction on top of this is not too hard now.

 

If you are looking for documentation on how to implement physics for rectangular objects, you should google "rectangle" and not "AABB", because AABB's are often just containers for broad-phase collision detection which is not what you are looking for.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Pinpickle   Members   -  Reputation: 108

Like
0Likes
Like

Posted 19 January 2013 - 12:21 AM

The problem is that while axis-oriented rectangles look simple from afar, their response to collisions is full of special cases. If your objects will always remain AABB's, especially if they can go in any direction at any velocity, your collision code gets quite tricky. The first step clearly is to implement collision detection and collision response.

 

The first one is rather easy and I'm sure you've already found links, but here is one. The second one is not too bad because if you model your objects as rigid, frictionless, nonrotating entities, you can apply conservation of momentum and solve for the two objects' final velocities, using the normal of the colliding side (which you can get from  collision detection). See how it is done for two spheres and you should be able to solve for the general case (hint: the reason objects identical in every way except their shape collide differently is because they have different collision normals). Implementing friction on top of this is not too hard now.

 

If you are looking for documentation on how to implement physics for rectangular objects, you should google "rectangle" and not "AABB", because AABB's are often just containers for broad-phase collision detection which is not what you are looking for.

Thanks for the post, I'll do some reading up on "rectangular" physics instead. Me searching for things like AABB just proves how little informed I am in this world of physics programming - it's good to learn though!

I don't want my engine to be frictionless (to allow for moving platforms and such), how much more complicated do you think that will make it?



#4 wildbunny   Members   -  Reputation: 550

Like
1Likes
Like

Posted 19 January 2013 - 06:35 AM

Hi there,

 

I wrote a series of articles about the process of creating a 2D platform game which uses AABBs exclusively for collision detection. Here is a link to the article which covered the collision detection and resolution:

 

http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/

 

There is some free downloadable source-code linked in the article as well which should get you off to a good start :)

 

Cheers, Paul.



#5 Pinpickle   Members   -  Reputation: 108

Like
0Likes
Like

Posted 20 January 2013 - 12:25 AM

Hi there,

 

I wrote a series of articles about the process of creating a 2D platform game which uses AABBs exclusively for collision detection. Here is a link to the article which covered the collision detection and resolution:

 

http://www.wildbunny.co.uk/blog/2011/12/14/how-to-make-a-2d-platform-game-part-2-collision-detection/

 

There is some free downloadable source-code linked in the article as well which should get you off to a good start smile.png

 

Cheers, Paul.

I had actually read several of your other tutorials on my way to finding out how to do this and so far they have been a big help! I hadn't found that particular one so thanks for linking that to me - your blog is a wealth of knowledge.

 

I think I found out my problem was just how stubborn I was being when it came to implementing a more complicated solution. If I ever saw "collision resolving" or other terminology that I thought to be remotely scary in a tutorial I'd just sort of switch off, I thought there would be an "easier" way to do it. There really wasn't so I started making an engine the proper way and things are starting to slot together and I'm realizing just how simple a physics engine can be. It's been an awesome way of learning and I may post some code here once I get it really smooth.



#6 Nyssa   Members   -  Reputation: 426

Like
0Likes
Like

Posted 28 January 2013 - 08:09 AM

I don't want to just implement a more comprehensive physics engine that already exists like Box2D

Unfortunately that's probably what you'll end up doing, and you'll spend alot of time doing it! I've tried to create a complete solution and it's not easy! You'll wonder where the last 12 months went smile.png

 

Creating a simple engine where a few objects will collide and bounce off each other isn't too bad, here's a good resource for that. If you start using lots of bodies however the calculations get pretty tricky.

 

 I don't want to just implement a more comprehensive physics engine that already exists like Box2D and just disabling rotation on every body as it has so many extras that I won't be using that will be wasting valuable processing time

 

I don't think you'll waste much processing time at all having rotational code there. But if you really insist then Box2D is open source so you could always just take out any rotational code?


Edited by Nyssa, 28 January 2013 - 08:09 AM.


#7 Milcho   Crossbones+   -  Reputation: 1177

Like
0Likes
Like

Posted 28 January 2013 - 08:34 AM

Not exactly AABB, but I had similar thoughts to yours, and ended up using physics based off the kinda popular n the way of the ninja game.

They have some very cool tutorials here: http://www.metanetsoftware.com/technique.html - which also include source (in .fla, but you can extract it with notepad++, and adopt it fairly easily)

 

Their source basically allows collision between AABB/Circle with different other shapes. The assumption here is that the 'other shapes' are static. It's more limiting than Box2D, it doesn't have complete physics simulation, but it allows for some cool stuff fairly easily. Since circles are radially symetrical, for example, I was able to implement a character that leans as multiple circles, which makes jumping physics puzzles a lot more interesting (since collision with corners, and slope in general is considered):

 

This is a screenshot of my implementation under c++:

 

You don't necessarily need to consider all cases.

You can extract the collision that basically performs AABB vs AABB collisions and use it as a quite simple method to do box vs box

 






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS