next »

[Glaiel-Gamer]

Is it better to calculate these based on the geometry of the shape, or is it better to let the client specify them directly.


I don't have any plans to let people "draw" shapes or anything.

Also is it better to store MASS or INVERSE MASS?

Also is it better to store MOMENTUM or VELOCITY?

I'm having a 3rd attempt at a physics engine (1st attempt was in flash, it was ugly and unstable a lot. 2nd attempt was in c++, it was better but unstable in parts and sloppy).

[BorisTheBrave]

Box2D's answers:
Either the density of the shape can be specified, or mass/COM/intertia can be set. Very few people use the latter option - inertia is pretty annoying to calculate. Most other engines also offer the choice, but specifying total mass instead of density.

Both mass and inverse mass are stored - though inverse mass is used in vastly more internal calculations. Similarly angular inertia. I guess the memory cost didn't justify bothering to optimize.

Velocity is stored. I think this is actually more often desired than momentum in the engine, and further, it gives less WTFs in the API as when people change the mass of shapes they don't expect the speed to change, etc.

Writing a physics engine is good for learning - but please, use one of the many already made engines when it comes to production games, there are lots of things that can catch you out otherwise.

[Glaiel-Gamer]

Writing a physics engine is good for learning - but please, use one of the many already made engines when it comes to production games, there are lots of things that can catch you out otherwise.

Ya unfortunately for my purposes I need to be able to expand me engine for approximate "bitmap to shape collisions". My levels change way too much and way too often for me to be able to parse it into a set of polygons, and looking at box2D's code to try to figure out what I'd have to do to expand that into it gives me a headache.

Besides I don't need anything as complex as box2D. Levels will have at most a couple boxes and a couple circles, nothing more since the game doesn't rely on the physics that much.

[BorisTheBrave]

It sounds like you are using polygons and rotation. This is a potentially painful mix already, imho, just fiddling around with the maths.

And you don't *need* to format stuff into polygons any more - Box2D supports line segments for static levels. Or you could hack it on using the API, it is not usually necessary to dig around in the internals in order to make non physical things happen. But fine, if you have a clear idea of exactly what you need, you're better insulated from physics quirks.

[Glaiel-Gamer]

Ya I can't use line segments cause my level is not static at all. It'll be easier to work a physics engine from scratch that I understand the internals, then hack in a bitmap collision function, than it would to try to hack it into box2D

You ever play my game closure?
http://www.newgrounds.com/portal/view/480006

I'm making the new one in c++ and trying to get physics in it. If I was using box2D I'd have to do some sort of polygon clipping algorithm to make it work, but that only works when my "light" layer is mathematically-defined shapes, but I plan on having a lot of crazier light stuff too and for the amount of objects I need to actually collide it will be faster to just do it brute forcey than to clip the level.

[BorisTheBrave]

Yes, I played (most of) Closure. You are right that it's a very difficult thing to do in Box2D, but that's because it's difficult to do with physics, full stop. Having written your own polygons and circles, you are still no better placed to actually make them behave as you want with regards to the background.

Using a physics engine doesn't stop you you writing this part for yourself.As I said, you wouldn't (necessarily) have to "hack" it into your engine of choice using a deep understanding of the internals. For example, you could easily implement a penalty based approach just by applying forces. Or if you wanted to do something based on sampling the background at various points, you can create small circles to correspond to the sampled points.

However, if I were doing this, I would hack into the engine itself, so I cannot blame you! I support your decision, just thought you'd be interested in the alternatives.


(In fact, platformers in general are quite hard to do with physics imho, just because standard platforming conventions are completely unlike physics, and no one wants to emulate legs properly)

[Glaiel-Gamer]

I'm giving up on trying to do my physics engine. I can't really get it to behave correctly.

Time to try hacking bitmap collision into box2D

[bateleur]

Time to try hacking bitmap collision into box2D

The thing about physics engines is that the hard part really isn't applying the results of collision, it's working out which precise collision has taken place. To do that with bitmaps you need to make simplifying assumptions, because you don't have any data for surface normals.

Box2D is a general purpose engine and doesn't play nicely with simplifying assumptions. You may find you get some rather odd results.

[raigan]

You should definitely read the collision section of this paper by Jamie who made Eets, it provides a pretty cool method for approximating the collision normal of two colliding bitmaps: http://www.eetsgame.com/PPCD/#_Toc44013730

AFAIK this isn't a perfect solution since it gives you only a collision normal; to find the full projection vector that Box2D will need you have to also determine penetration depth, which the above handles via bisection. Unless you're trying to get crazy numbers of objects at once it's probably fast enough though.

An alternate solution (related to Jamie's method) would be to use a signed distance map, here's a good intro if you're not familiar with the term: http://lab.polygonal.de/2008/07/13/collision-detection-for-particle-systems/ You problem now becomes how to generate a signed distance map from a bitmap rather than from a polygon, but that seems like a common problem that should be tractable (I don't have any good papers OTOH since I prefer to work with polygons).

I agree with bateleur -- most of the difficulty of "physics" is really collision detection, and  generating good collision information is probably harder than solving a set of constraints.

Writing a simulator on par with Box2D is definitely a huge undertaking; having said that, it's very generic so if you have specific needs which it doesn't perfectly address, it _might_ be worth writing your own system.

For instance if you only need non-rotating or kinematically-rotating objects (i.e "particles" rather than rigid bodies) you'll definitely be able to make a special-case engine which outperforms Box2D. As your required functionality begins to overlap that of Box2D, the value of doing it yourself decreases.

I know from experience because we're working on our own physics system -- in our case we really wanted super-stable jointed characters, and we need to be able to create custom constraints since we're doing a lot of weird physics-based animation stuff; the former was a bigger problem before 2.0 (joints are now pretty good), but the latter is a deal-breaker because Box2D's constraint solver is beyond incomprehensible for us. And we wanted deformable shapes, which aren't currently supported in Box2D. Plus we're really into this stuff and wanted to learn more about it

In the end it's debatable whether we would have been better to just plug our own constraint solver into Box2D, or just learn to work within its limitations. Then again it's really nice to work with code that specifically designed for your application and that's a lot easier to wrap your head around since it's not someone else's API. Also we'd rather not get into C++ yet

[Glaiel-Gamer]

Ya I don't need to collide 2 bitmaps, just Circle to Bitmap and Square to Bitmap, which I already have the algorithms to do so worked out in my head.


To estimate the surface normal, you pick a point around the edge of the bitmap (doesn't have to be ON the edge, just within a radius of the edge) and a radius


You check points around that circle and sum up the ones which are colliding, then divide by the number of points ("average the points") The normal will the line from that averaged point to the center of the circle. For a circle, the harder part is finding the penetration depth (cause I can find the contact point by center-normal*radius). So I'm probably going (and this goes for squares too) to do the test in a for loop multiple times, backtracking the positions by normal*i until none of them collide anymore, then i is the collision depth (until I find a better way, but I can't feasibly think of a better way to do so). If I was using a static level I could store a second map where the color represents collision depth and one where it stores collision normal for each pixel, but if I was using a static map I could just estimate it with a mesh instead.

For a box, I'm just going to have to calculate the normal like this by first getting the points it's colliding with, then averaging them and using that point as the center point to test the circle normal with (gonna have to play around with this, might make more sense just to average the normals at the corners).

This whole shin-dig of a game is going to be oh so fun of a summer project, considering I've only known c/c++ for about 6 months now, and I have to be teaching myself how to use shaders at the same time. It's all worth it though.

[raigan]

If you don't need rigid bodies (i.e you just want physics-based translation, not rotation), don't need constraints between objects, and only need circles and rects vs bitmaps, you might be better off with home-made. At least, Box2D is overkill so getting to grips with it enough to add your desired features might be just as much work as making a simpler system. Then again, once you do get stuff working in Box2D you have the option to start using rigid bodies, constraints, etc.

Depending on the scope of the game you could always try an explicit geometry-based approach, using Box2D's static edge shapes. AFAIK you can just clear the world and add a new set of collision edges each frame -- provided the edges don't move too much between frames, objects on them will be pushed out/moved along appropriately. For Closure-type effects you'd need to define the light shapes as polygons and then CSG them with themselves (to weld overlapping lights into a single polygonal shape) and then against the world (to delete anything not within the lit regions).

I guess getting bitmap-based collision might be simpler, I'm just personally terrified of them since there aren't really any "known" good solutions, it's all ad-hoc and might never work, whereas computational geometry has lots of nice references and tutorials explaining how to accomplish things with polygons

[Glaiel-Gamer]

I need rotation, pushing boxes along slopes doesn't look good without rotation :p.


I have considered CSG, but due to the nature of Closure's engine and how lights can be "added" together to create shapes other than simple combinations of circles, and how I'm adding non geometric lights in the new version, CSG is more trouble than it's worth.

Again though, I'm imposing limits on what I need from the bitmap engine. Simple shapes, high friction, low numbers of shapes. I've seen and implemented circles to bitmaps and seen it work just fine, so honestly the hardest part will be figuring out how to handle square to bitmap, it's simpler by a long shot than trying to get accurate behavior for an irregular or elongated shape, which would require more hotspots than its worth.

[BorisTheBrave]

It's equivalently hard, actually. Once you've got square-bitmap working, convex polygons are little extra effort, and then arbitrary polygons composed from that automatically.

Box2D is certainly overkill for most games, but by the time you've said rotation+polygons, it's time to switch.