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).

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?

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.

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?

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.

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...

I have never designed a physics engine myself but when I was thinking about writing one I turned to the resources on this site

http://www.d6.com/users/checker/dynamics.htm

In theory Phyx support per pixel collision with pMaps.

>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.

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