Archived

This topic is now archived and is closed to further replies.

AngelForce

2D Physics Engine Design

Recommended Posts

Soon I am going to start implementing my own 2D physics engine (hopefully with rotation, constraints, friction etc.). After reading quite a few articles I hope that I will be able to cope with (most of) the problems which are going to arise surely when beginning with the actual coding. At the moment, I am still in the design phase and wonder how to structure the engine best. This is what I have so far (one timestep): 1) Compute forces and torques 2) Enforce constraints (except for generell collision) 3) Compute accelerations 4) Integration step 5) Find all contacts (= collision detection) 6) Resolve colliding (penetrating) contacts (= collision response, apply impulse) And now I am not sure: What to do with resting contacts? Should they even be treated differently from colliding ones? If yes, when to compute the forces to cancel out interpenetration? Clearly this must happen after finding all contacts, but then the forces would only become visible the next timestep. (Or should I just apply an impulse for them too, treating them the same as colliding contacts?) At the moment, I am kind of lost. It seems that before detecting collisions I have to integrate, but the resting contact forces are only available after finding the contacts, so they will not be considered by the integrator (at least not during the same time step). I would be very glad if you could help me out (what am I doing wrong, are there better ways etc.) or even tell me how you structered your physics engine. Thanks for your time!

Share this post


Link to post
Share on other sites
I''m actually working on the exact same thing. While working on suspending objects in the air via "rope" I began to notice the need for including Normal forces into the engine which is actually causing me to rewrite alot of what I already have. So far I''ve been using velocity and mass for physics modellings which indirectly includes the forces involved but now I''m moving toward giving forces a bigger role in the engine. Haven''t done it yet so I can''t say how I chose to do it but it will be done soon so I''ll let you know or if you give me more info on how u plan to implement the ojbects your engine will interact with I can help you come up with ideas and ways to implement them.

Share this post


Link to post
Share on other sites
I am not sure yet... in fact, nothing has changed of my dilemma as yet. If I will be able to work something out which makes sense for me I will tell you for sure

Also at the moment I do not have a lot of time, but when I find some (maybe below the bed?) I might take a look at other people''s code and try to figure out how they did it.

Yet I am still hoping that maybe someone else can help me. Nobody out there who can give some advice?

Share this post


Link to post
Share on other sites
I have found an interesting document to read: Clicky
It is about how to structure a physics engine (that's what I wanted ). Yet there are different ways to do things, and I would especially be interested which one would be most suitable for a game, and why.

Has anybody else here implemented a physics engine and how does your one-frame-loop look like? (pseudo-code)

Thanks for your time.

[edited by - AngelForce on May 21, 2004 5:41:14 AM]

Share this post


Link to post
Share on other sites
I did implement a few demos, but they are far less complex than the stuff in that document (very good, BTW). If you have a look, you''ll see the problems with the very basic method I use.

2D box collision

Share this post


Link to post
Share on other sites
quote:
Original post by oliii
I did implement a few demos, but they are far less complex than the stuff in that document (very good, BTW). If you have a look, you''ll see the problems with the very basic method I use.

2D box collision



But it''s a nice demo nevertheless

I am not dead yet, maybe today I''ll find some time in which to make my mind up how to design my engine.
I''m still hoping that maybe someone else will add to this discussion. Maybe I have posted in the wrong forum? (Not frequented enough?)

Share this post


Link to post
Share on other sites
I''m also struggling with the same stuff. I''ve found the articles from Chris Hecker and David Baraff very useful.

Share this post


Link to post
Share on other sites
it''s the right place to post that kind of stuff. looks like people are either busy or on holiday Myself, it''s busy busy.

besides, physics engines are extremely complex, and that''s kind of the higher end of the spectrum. But I''m still quite surprised you didn''t get any more interest from this, the doc is very good, and your problem is an essential part of a physics engine. Comparing your method, or the methods outlined in the paper, to the internal systems used by professional physics engines (ODE, Tokamak, Havoc, Math Engine, Newton) would be very interesting. I guess there aren''t that many software engineers who successfuly implemented a solid engine.

Share this post


Link to post
Share on other sites
Well, as of now I know a little bit more than when I posted first

I actually think that this document on how to structure an engine is quite good - but I don't really understand why to have two inner loops for computing the physics of one frame (one in the Time Control module and one in the Motion Solver module). Why not use something like this: (pseudo-code, I hope I did not forget too much...)


//next_time = time when next frame will be drawn

for(current_time < next_time)
{
//integrate small TIMESTEP and enforce constraints

{
integrate forward;
call collision detection; //= get all contacts

enforce constraints; //e.g. resting contacts

}
//collision detection has already been called!

check for colliding contacts;

if(penetration too deep)
{
integrate backwards; //means just use last state

set TIMESTEP to be even smaller;
}
else
{
solve collision(s); //(=colliding contacts)

current_time += TIMESTEP;
}

//maybe check here that you don't spend

//5 hours in this loop

}


Note that this would use the (simple, solid but maybe slow) Backtracking approach to find the 'exact' time of collision.

Did I miss/forget anything?

Please post your comments

[edited by - AngelForce on May 23, 2004 5:55:09 AM]

Share this post


Link to post
Share on other sites
ive been thinking about this also, and i came up with this:
(my collision mesh data structure is an aabb for each object, with objects consisting of a small number of simple convex hulls each bounded by a bounding sphere.)


main loop{
while curtimecol=collision(targettime)
if col!=null handle collision
}

collision routine(targettime)
sweep n prune with aabb''s
for all colliding aabbs: numerical root finding algo on bounding circles of convex hulls.
for all colliding boundig circles: binary time search on convex hulls themselves.
return first collision


this in only a start though. as you can see there are no resting contacts or sliding or whatever taken into acccount.
i think ill handle them with a seperate contactpoint object, its a well documented method.

Share this post


Link to post
Share on other sites
quote:
Original post by Eelco

main loop{
while curtimecol=collision(targettime)
if col!=null handle collision
}

collision routine(targettime)
sweep n prune with aabb''s
for all colliding aabbs: numerical root finding algo on bounding circles of convex hulls.
for all colliding boundig circles: binary time search on convex hulls themselves.
return first collision




But with this structure, won''t you take only the ''first'' (what''s the first? The first found or the first in time?) collision in account?

Share this post


Link to post
Share on other sites
Well, as nobody seems to contribute anymore, I''ll let this thread die and try to code (after I finished my design of course) something useful. As soon as I have something, although, you can be assured that I''ll show it off here

But it might take soooome time... I am just way to occupied!

Share this post


Link to post
Share on other sites