next »

[slembcke]

I read that page as well a couple years back. Their tutorials are what convinced me to use SAT based colliders before I started work on Chipmunk. As far as traversing Chipmunk's spatial hash's grid, I used this as a good tutorial: http://playtechs.blogspot.com/2007/03/raytracing-on-grid.html

That blog is always a good read.

[encoder]

happy new year dear 2009 topic

don't know about other languages but what as3 is concerned b2d is just best out there.

you can go with other engines though and get good results, without glitches, but they tend to eat up more resources. what box2d lacks is ease of implementation. you may write 5 times more lines then on other frameworks. therefore more and more people write a simplified shell for it and then use it trough that shell.

for the learningcurve...
i managed to "master" it in 3 days.

[rivon]

I hope you guys don't mind me resurrecting this topic.

I'm currently trying to write a game with some special gameplay and I'm using Box2D but I've ran into a problem and I thought that maybe Chipmunk is doing the physics differently so there won't be the problem.

So, someone who knows Chipmunk, how does Chipmunk do collision correction?
AFAIK Box2D does it by applying impulses (just adding a vector to the velocity) to objects and thereby correcting their positions via normal movement. But that's a bit a of a problem for me.
I'd like the engine to correct the positions of objects right when the collision occurs, by moving the objects to non-colliding positions and not changing their velocity (well, it could of course slow objects down because of collisions and stuff, but it should not correct the collisions by changing objects' velocities). Is it somehow possible? Is Chipmunk doing it that way? Or possibly any other 2D physics engine?

[slembcke]

Hey rivon.

Actually Chipmunk, Box2D and a lot of physics engines do position correction of overlapping objects the same way. I'm not sure if it's the official name of the algorithm, but Erin Catto calls it "pseudo velocities". Basically you solve the position error as a non-persistent velocity that gets added to the regular velocity only when updating the position. It's what causes objects to act a bit like sponges when overlapping.

The issue is that it's cheaper to allow overlap and fix it over time than to disallow it in the first place. Continuous collision detection can help with this, but can become extremely expensive. It also doesn't completely make the problem go away as you will inevitably end up with overlapping objects from persistent contacts anyway with an iterative solver.

Your best bet is to use a fixed size timestep if you aren't already and decrease the size of the timestep you are using. Chipmunk can sort of help out in this regard as it is much faster. That would allow you to run smaller timesteps without increasing the CPU load as much. If you are on a desktop machine the CPU load probably isn't much of an issue though.

[rivon]

So you're saying that there currently isn't any engine like that?
The performance isn't critical in this case as there is only one dynamic body moving and the rest is just environment of static bodies.