could box2d handle say 500 circles/boxs within this simple geometry say 1msec MAX on 2ghz machine?
It doesnt have to give 100% accurate results just similar to what I have now, if a sphape enters a polygon, push it out
cheers zed
Box2d is it fast?
Author
Ive had a look at the demo but couldnt really glean the info from the demo suite
One thing ive noticed over the years is 3d physics libraries crash + burn in the following situation.
polygon mesh soup (doesnt even even have to be high polygon count)
100s of objects (spheres/boxes etc) in close proximity inside this meshsoup
The reason they crash + burn is cause they go for accuracy over speed (which is laudable) but doesnt make for responsiveness.
Im looking at something similar to this
could box2d handle say 500 circles/boxs within this simple geometry say 1msec MAX on 2ghz machine?
It doesnt have to give 100% accurate results just similar to what I have now, if a sphape enters a polygon, push it out
cheers zed
could box2d handle say 500 circles/boxs within this simple geometry say 1msec MAX on 2ghz machine?
It doesnt have to give 100% accurate results just similar to what I have now, if a sphape enters a polygon, push it out
cheers zed
I've done some test with Chipmunk and it can push about 300 closely packed circles in a scene at about 40fps, this is in addition to the overhead of drawing the circles and also the game logic, on a AMD 64 1.3Ghz. So if your capping your framerate about 30fps and optimize the drawing you can probably push 300-500 closely packed spheres ok, if your aiming for atleast that CPU speed. Be aware, modern CPUS are multi-core now and since none of these 2d physics engines support multi-core yet and each core is probably less powerful than the AMD, you might not be able to push as many circles, even though overall it has more CPU power.
Good Luck!
-ddn
Good Luck!
-ddn
Quote:Original post by zedz
could box2d handle say 500 circles/boxs within this simple geometry say 1msec MAX on 2ghz machine?
It doesnt have to give 100% accurate results just similar to what I have now, if a sphape enters a polygon, push it out
cheers zed
I don't know about 1ms, but I had a test application running with around 500 polygons (more expensive than circles by far) colliding quite cheerfully within a vsynched framerate of 75 fps. Framerate made about 200 fps on my machine (2.4ish GHz, fairly nice graphics card) with vsynch off.
Bear in mind Box2D, like most physics engines, can send non-colliding objects to sleep so the actual performance is not quite as simple as "how many objects". It depends how densely packed they are, how many are moving, colliding etc.
I haven't ever tried using Box2D with polygon soups though. I think the edge primitives are still in the SVN rather than the official release (although don't quote me on that).
Basically though, hell yes, Box2D is fast [smile]. You can control the number of iterations of the solver per frame so less iterations means faster but less accurate.
I'm not sure what the standard is since the only physics engines I have used are box2d and ode 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 vs ode where you can create separate spaces for things like static terrain, dynamic bodies, picking, items, ai vision and script triggers.
Quote:Original post by Kaze
I'm not sure what the standard is since the only physics engines I have used are box2d and ode 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 vs ode where you can create separate spaces for things like static terrain, dynamic bodies, picking, items, ai vision and script triggers.
I haven't got round to using them yet, but is this not what Box2D's sensors are for? I don't know how efficient internally they are but:
Quote:Box2D User Manual
6.2.4. Sensors
Some times game logic needs to know when two shapes overlap yet there should be no collision response. This is done by using sensors. A sensor is a shape that detects collision but does not produce a response.
The only issue I've seen people complaining about on the forums is that it is a bit unwieldy to create shapes on the fly per frame just to use as sensors - creating sensors at startup that persist does not seem to be a problem.
I've been pretty happy with Box2d. Not quite sure how well it passes your test. I'd expect it to handle at least a few hundred objects in close proximity.
But I'm not quite sure you'd want the power of Box2d if you're not doing heavy physics. What you could try is creating all your shapes as sensors, and then simply handle collision response yourself.
But I'm not quite sure you'd want the power of Box2d if you're not doing heavy physics. What you could try is creating all your shapes as sensors, and then simply handle collision response yourself.
Quote:Original post by EasilyConfused
I haven't got round to using them yet, but is this not what Box2D's sensors are for? I don't know how efficient internally they are but:
Sensors don't send collision data to the physics calculations but thats about it.
Quote:Original post by EasilyConfused
The only issue I've seen people complaining about on the forums is that it is a bit unwieldy to create shapes on the fly per frame just to use as sensors - creating sensors at startup that persist does not seem to be a problem.
I think the annoyance here is you can't just test a shape against the box2d world, you have to create it, update your world and collect the collision data generated by that sensor by filtering it out of the returned collision data of every other object. This makes AI programming a bit of a pain.
Quote:Original post by KazeQuote:Original post by EasilyConfused
I haven't got round to using them yet, but is this not what Box2D's sensors are for? I don't know how efficient internally they are but:
Sensors don't send collision data to the physics calculations but thats about it.Quote:Original post by EasilyConfused
The only issue I've seen people complaining about on the forums is that it is a bit unwieldy to create shapes on the fly per frame just to use as sensors - creating sensors at startup that persist does not seem to be a problem.
I think the annoyance here is you can't just test a shape against the box2d world, you have to create it, update your world and collect the collision data generated by that sensor by filtering it out of the returned collision data of every other object. This makes AI programming a bit of a pain.
Yeah, that's pretty much what I've seen on the Box2D forums. I think the problem with integrating the above sort of feature, from what I've read some of the b2 experts saying, is that it is hard to get it to play nice with the continuous collision detection.
Author
thanks guys, its sounds as if box2d isnt quite to the state I wish at the moment.
especially this
All my objects will be awake thus have to be tested.
ATM cpu time consumed by
-AI largest slice
-physics
-particles
-render setup
Actually Im quite pleased as I dont have to spend time to integrate this into my game :)
especially this
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 infowhich sounds like I cant have various collision materials, eg objA == matA && objB == matA dont worry about colliding
All my objects will be awake thus have to be tested.
ATM cpu time consumed by
-AI largest slice
-physics
-particles
-render setup
Actually Im quite pleased as I dont have to spend time to integrate this into my game :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
