Sign in to follow this  
Thomas Mathers

2D Physics Simulation & Per Pixel Collision Detection.

Recommended Posts

Thomas Mathers    128
I am currently working on a 2D sidescroller game with two other friends. Due to the shape of our sprites I have had to implement per pixel collision detection using bitmasks. This was was fine and dandy up until the point where we wanted to physically simulate our sprites. Since I have not taken any physics or math courses in university yet I decided that I would integrate a commercial physics engine rather than implementing my own. However this causes many complications. Since most physics engines use primitives for collision geometry, per pixel collision detection cannot be accomplished. Is there a way for me to intercept the collision calls and then only allow a collision if it passes the per pixel test? Or must I be forced to implement my own physics engine? Oh and for reference I am using the PhysX engine (a.k.a Novadex).

Share this post


Link to post
Share on other sites
What?

you were talking about per pixel stuff, which is fine

then all of the sudden you got into physics engines....
how does your sprite equate to collision geometry in some engine? I dont see the connection, rather you didnt say it

I mean... a sprite is just some graphics, while collision geometry is math and polgons... are you 'tracing' over your sprite with triangles or something to make an approximate shape for the physics engine?


uhh, for lack of other details I will just say
why not do your pixel test, and if it doesnt collide, turn off the physics engine?

Share this post


Link to post
Share on other sites
Thomas Mathers    128
hmmm...

I thought my post was rather self-explanitory. I am using a physcs engine to simulate my sprites. Since most physics engines only use simple primitives (such as boxes -- just make it clear what a primitive is) to perform collision tests, per pixel collision detection cannot be accomplished (As the physics engine does not care what pixels are colliding only what primitives are).

I hope that makes it much more clear.

Share this post


Link to post
Share on other sites
Adam Hamilton    271
I understood what you meant - The technical term for the collision geometry are bounding boxes or bounding spheres. Some even go down to triangle collision as a last resort.

If there is no way to hook the collision event then you may have to implement a physics engine yourself. I don't think it would be too hard to implement a physics engine for a 2D game. The maths isn't that difficult.

What kind of physics do you wish to simulate?

Share this post


Link to post
Share on other sites
Thomas Mathers    128
I just need support for changing things like linear velocity, angular velocity, applying forces, and perhaps joint support. If you could perhaps point me in the right direction on how I would go about implementing this stuff, it would be greatly appreciated.

Share this post


Link to post
Share on other sites
just because your Sprite is rendered as a texture on a quad, doesnt mean the physics model for your object also has to be a box
pixels, also do not provide information a physics model would want, such as surface normal at point of collision

id recommend, for every sprite, you also build using Multiple physics primitives, such as boxes and trianges and other shapes combined, an Approximate physics object that resembles the Sprite graphic. Then the physics model is happy doing its thing, and you still have reasonable looking collisions...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
In theory Phyx support per pixel collision with pMaps.

Share this post


Link to post
Share on other sites
syph    140
>linear velocity, angular velocity, applying forces, and perhaps joint support

For a 2D platformer you really don't need fancy physics. With the exception of joint support, this is simple enough that I suggest you just write your own "engine".

Here's a break down:

Velocity: how fast and in what direction something moves. Simply add the velocity vector to your sprite position.

Acceleration: how fast your velocity changes. Simply add your acceleration vector to your sprite velocity.

Angular: replace the word "position" with "angle" in my last two explanations. (ok, a little more complicated, but not much more!)

Forces: Force = mass * acceleration, => acceleration = force/mass. Assign a mass to your sprites, figure out the force exerted, and calculate the acceleration produced. Then apply the acceleration as above.

I've never done joints, but that would be much trickier - do you really need them?

I'm not trying to trivialize your problem, but this really is a doable by anyone with a good grasp of algebra. You'll have more control over your code and have a better feel for the physics if you do it yourself. The physics section for my platformer is maybe 300 lines of code, and most of that is collision detection/response. I can post some samples if you want.


Share this post


Link to post
Share on other sites
RobAU78    206
Is the engine you're using open-source? If so, you could directly add in a method (or modify/replace the existing one) for collision detection that implements per-pixel detection. Otherwise, there is a refactoring pattern called Introduce Foreign Method (in Martin Fowler's Refactoring book) that you could get by with using. Basically you would create the necessary method in your "client" (i.e. your game) and it would take an instance of your "server" (i.e. your physics engine) as the (first) parameter. Fowler also suggests commenting the method with "foreign method, should be in *server*" to make it easier to find later.

Let me know if this helps. :)

- Rob

Share this post


Link to post
Share on other sites
Rob Loach    1504
If you use a dedicated physics engine like ODE, you can put use to something called Plane2D which just forces the z axis of your objects to 0. Although I haven't had any experience with it, Seriema got it working.

As for alternatives, you could just roll your own physics engine, checking distances between objects. For Blastoids, I just did a simple circle collision check to see if the asteroids hit the ship. It really depends on what's required of your gameplay.

Share this post


Link to post
Share on other sites
SanityAssassin    199
Quote:
Original post by Thomas Mathers
I am currently working on a 2D sidescroller game with two other friends. Due to the shape of our sprites I have had to implement per pixel collision detection using bitmasks. This was was fine and dandy up until the point where we wanted to physically simulate our sprites. Since I have not taken any physics or math courses in university yet I decided that I would integrate a commercial physics engine rather than implementing my own. However this causes many complications. Since most physics engines use primitives for collision geometry, per pixel collision detection cannot be accomplished. Is there a way for me to intercept the collision calls and then only allow a collision if it passes the per pixel test? Or must I be forced to implement my own physics engine?

Oh and for reference I am using the PhysX engine (a.k.a Novadex).


Here is my take: You can use PhysX just fine with your sprites.

Think of your sprites as a purely graphical object. Then think of physics bounding boxes (or spheres) surrounding your purely graphical object. When you initialize the game (or when you create a sprite, it's your choice), create physics objects (or rigid bodies) that represent your sprites' physical properties (e.g., shape, mass, materials, etc.). Then add them to your NxScene.

With every game update, update your physics via PhysX (e.g., NxScene::simulate( deltaTime ), then when the physics is done doing it's work, update your sprite's position and orientation by querying PhysX for it (e.g., NxActor::getGlobalPose() or NxActor::getGlobalPosition() and NxActor::getGlobalOrientation()).

Admittedly, using bounding boxes and spheres may not EXACTLY match your sprites geometry, but you can usually get pretty close. And you have to ask yourself, just how close do you really need to get to make your game work and be fun?

Beyond that, if you need to have closer approximations to your sprites geometry, I'd recommend you look at PhysX's use of compound geometry (I think PhysX calls the concept Multishape Actors--> see Lesson 112 in their tutorials).

Good luck!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this