🔒 Locked

Physics engine development

Started by daniel_i_l Dec 23, 2006 at 2:41 PM 6 replies 1.8k views

Original Post

Dec 23, 2006 at 2:41 PM

Hi, I've been working on a physics engine for 2 months and have made considerable (for me) progress. So far i'm workings only with OBB's, the boxes stack properly, deactivate and activate properly, and it can maintain a good framerate with around 100 boxes. heres a short movie of a brick wall that gets hit with another block: movie of wall but now i'm unsure of how to precede - what should i do next? -add more primitive shapes such as spheres and cylinders -spatial partitioning -joints -there's more than i can't think of at the moment currently i'm not really sure what to do so when ever i get some free time i just play around with what i have. what's the best thing to do next? Thanks. (comments on the movie would also be helpfull)

tthibault

Dec 23, 2006 at 4:09 PM

Hey, looking really good. Was it running at less than 20FPS because you were recording it? What did you use, fraps?

What you have listed tends to be the natural development for people that write physics related programs.

Raghar

Dec 24, 2006 at 7:07 AM

The best way how to record output from 3D engine is: redirect output as images into a directory (you need big HD space), or at some frame server (you need to decide on format of video file beforehand). It's easy to pause 3D engine until the redirector method returns.

Would virtual dub work for these purposes?

coderchris

Dec 24, 2006 at 7:09 PM

Looking good :)

I think a very important thing you should add is spatial partitioning since this will let you have a whole lot more objects simulated without slowing it down too much.
This probably is not something you would want to do right now, but you can increase the speed alot by using SIMD instructions. I switched to using these in my vector and matrix classes and it gave me a huge performace boost

Quick question though, how are you doing your collision detection? Are you using a special OBB vs OBB method or something more generic like GJK or seperating axis thm.

billy_zelsnack

Dec 25, 2006 at 2:15 PM

I'd hold off on the spatial partitioning. You can easily get away with hundreds of objects brute force.

From your list I'd first add a sphere, not because it is simple, but because it is an excellent primitive to debug with.

After that'd go to joints.

daniel_i_l

Dec 28, 2006 at 5:07 AM

Thanks for the input.
For the collision detection i'm using the SAT.
And Billy - should the engine be able to simulate (with a high frame rate)hunderds of blocks by brute force even when they're stacked up in a brick wall, for example - a wall 20 bricks wide and 20 tall? Should i try to get to that stage before including SP?
Thanks.

billy_zelsnack

Dec 28, 2006 at 3:42 PM

Funny you should mention 20x20.. I remember 400 the point where brute force really started to fall apart. I did that stuff awhile ago so the machine wasn't so large (800mhz I think), so you could probably get away with more than that today. Probably not much more as brute force turns to crap really fast after a certain point.

It's really easy to get hell bent on optimizing one tiny portion. I'd say once you get it to a reasonable minimum working point (not dropping frames in small test scenes), go ahead and add a few more features. You might find out that your new features end up driving future optimizations.

stbuzer

Dec 30, 2006 at 3:16 AM

You'll really need something like sweep and prune broadphase in physics engine release, because brute-force O(n*n) broadphase fails on complex scenes from real applications(even if the bodies are inactive\frozen).
Joints are also necessary :)
Video looks good, good luck!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.