🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Box2d is it fast?

Started by
18 comments, last by grhodes_at_work 15 years, 4 months ago
Quote: Original post by zedz
All my objects will be awake thus have to be tested.
This implies that you apply a force to every single one of your 500 objects, every physics timestep?
Quote: ATM cpu time consumed by
-AI largest slice
-physics
-particles
-render setup
Mine goes more like this: Particles, Graphics, Physics, and lastly AI.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Advertisement
2D physics engines can handle a lot of objects. Just look at:
Glaze Physics Based on Chipmunk
Quote: Original post by zedz
Quote: but the main disadvantage I find with box2d is that their is no separation between the physics and collision detection systems so if you don't need every object to interact with every other object your going to waste a lot of cpu power filtering out useless collision info
which sounds like I cant have various collision materials, eg objA == matA && objB == matA dont worry about colliding


Not at all - Box2D has a built in system (that can also be easily overridden if you need to) to specify collision filters. I think Kaze was referring to the fact that you have to actually have an active, physical body as part of the world to test against with whatever minor overhead that involves. Filtering to ignore collisions between different types objects is pretty easy.

Quote: Original post by zedz
Actually Im quite pleased as I dont have to spend time to integrate this into my game :)


That's fair enough [smile]. I've been following this game in your journal and you seem to be doing fine as it is. I just thought I'd clarify the above.

heres a screenshot of a bad senerio 750objects all active + are moving about.
there are errors, eg the green circles penetrating the geometry + other circles, which I can live with, what is not acceptable though is a drop in framerate, + with a fixedloop as you know any drop just compounds baddly.

Quote: I think Kaze was referring to the fact that you have to actually have an active, physical body as part of the world to test against with whatever minor overhead that involves
ok like having a linesegmenttest for say particles

Quote: Mine goes more like this: Particles, Graphics, Physics, and lastly AI.
the opposite to me, AI is top for me because X number of aliens have to pay attention to what other aliens are doing (boids) + when theres lots this can potentially become expensive (in fact I had to rewrite part of my scenegraph to deal with this)

btw for those interested - dont worry about downloading the latest game demo, theres a bug I forgot to remove. Ill rectify that next time round
Are you using any kind of spatial partitioning to reduce the number of actual fine-grained pair intersection tests you need to do? This won't help with the errors as it is almost impossible to get this right with a density like that without a lot of iterations of the solver per frame, but it might improve the framerate.

The N tutorials have a good discussion of using a simple grid-based spatial partitioning system.

Also, you may be doing this already, but an AABB is very cheap to compute for a circle so you can avoid a lot of more expensive circle-circle tests by pruning out any pairs of circles whose AABB's don't intersect (again, a very cheap test).
Quote: Original post by EasilyConfused
Not at all - Box2D has a built in system (that can also be easily overridden if you need to) to specify collision filters. I think Kaze was referring to the fact that you have to actually have an active, physical body as part of the world to test against with whatever minor overhead that involves. Filtering to ignore collisions between different types objects is pretty easy.


You can filter the collisions but I'm pretty sure filtering is all it is and it doesn't optimize the groups in any way.

for example if you 3 groups

A: for terrain
B: for creatures
C: for particle effects

where particles ignores bodies and both terrain and particles ignore other terrain and particles respectively

even if creating and filtering the collision info for one object is insignificant it not going to take long before

(A + B + C)^ 2

gets a lot bigger than

(A*B) + B^2+ (A*C)

Quote: Original post by Kaze
Quote: Original post by EasilyConfused
Not at all - Box2D has a built in system (that can also be easily overridden if you need to) to specify collision filters. I think Kaze was referring to the fact that you have to actually have an active, physical body as part of the world to test against with whatever minor overhead that involves. Filtering to ignore collisions between different types objects is pretty easy.


You can filter the collisions but I'm pretty sure filtering is all it is and it doesn't optimize the groups in any way.

for example if you 3 groups

A: for terrain
B: for creatures
C: for particle effects

where particles ignores bodies and both terrain and particles ignore other terrain and particles respectively

even if creating and filtering the collision info for one object is insignificant it not going to take long before

(A + B + C)^ 2

gets a lot bigger than

(A*B) + B^2+ (A*C)


Very true.

Certainly would be nice if B2D had some kind of support for filtering out entire groups from each other, but then I don't understand enough about how it works under the hood to comment on how feasible that would be.
I am wondering why you don't discuss this on the Box2D forum and prefer a more general place like GameDev.net instead. In my opinion Box2D is one of the best 2D engines out there. It is good for learning things and also to make a 2D game. All the decisions made there are well thought through. The separation between collision and physic is something lots of studios are wishing for, but from a physic engine programmer side this makes a lot of stuff extremely difficult and the physic system can be abused a lot this way. Even Havok and nVidia have the collision coupled with the physics. You can make very good games this way (e.g. Halo which uses Havok), but you have to rethink some approaches how you do your stuff a little. That is what the forums are for. I know that the ODE does this separation, but the ODE is not a mature engine. To my knowledge most games that used it like e.g. Stalker didn't use its collision detection at all nor does it support continuous collision. Also some of the joint constraint formulations are wrong, etc...

Cheers,
-Dirk
Quote: I am wondering why you don't discuss this on the Box2D forum and prefer a more general place like GameDev.net instead.

2 reasons
A/ sign up to the forum, + post a single question (if its not for me) + then only to bugger off
B/ Im thinking perhaps the answers wont be unbiased/unemotive (sorry cant express the right word)
There has been some general discussion here about how physics engines are able to accelerate things, which makes it relevant to this forum even though there is a heavy box2d component. I will say, though, that I would rather not see a lengthy discussion of the internals of or how to use box2d here. If that part of this discussion needs to continue, then that is something that belongs in the box2d forum and I would ask that the original poster take the discussion over there!
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net

This topic is closed to new replies.

Advertisement