Version 0.1 Alpha Release: Irrlicht Dedicated Physics Engine

kine · Post by **kine** » Sat Jan 22, 2011 7:07 am

@Luben: David H. Eberly 's "Game Physics" is a very good book

Alpha Omega · Post by **Alpha Omega** » Sat Jan 22, 2011 10:49 pm

I am very pleased to announce that the collision portion of the engine is completed, now I am shifting my focus onto world collisions instead of obj/obj collision. The videos I have been posting do not do it justice so I got a decent video to showcase here....

http://www.youtube.com/watch?v=_Cdx2GFDFsg

Please enjoy the physics.

Comments suggested for future features. 3 weeks in the making and already close to alpha release which will hit once I finish world collisions

.

Radikalizm · Post by **Radikalizm** » Sat Jan 22, 2011 11:08 pm

Wow, you're making progress quite fast, what kind of framerates do you get on that last video? (and on which hardware?)

And how are you implementing the physics node-wise? Are you using irrlicht's animator system or are you managing physics complete separately from regular scene management?

Alpha Omega · Post by **Alpha Omega** » Sat Jan 22, 2011 11:24 pm

Radikalizm wrote:Wow, you're making progress quite fast, what kind of framerates do you get on that last video? (and on which hardware?)

And how are you implementing the physics node-wise? Are you using irrlicht's animator system or are you managing physics complete separately from regular scene management?

That last video I was getting 60 FPS in game with 300 box-particles brute forcing collision calculations every frame. Of course this can be optimized with certain checks but they have not been implemented yet. I do not use irrlicht animator system at all. I basically have made my own manager physics side and have irrlicht do the graphics side.

I dont know what irrlicht animator system has to offer but for now its not needed. That video was run in realtime using hypercam's laggy self to film it.

I am running a quadcore AMD Phenom II 965 with 4 GB of 1600 Mhz Ram on Windows 64 bit.

Also if the Irrlicht community is interested in using this code, the project will need a nice name to show off Irrlicht engine capabilities.

Radikalizm · Post by **Radikalizm** » Sat Jan 22, 2011 11:35 pm

Some time ago I implemented Havok rigid body physics using irrlicht's animator system to update node transformations, I only used a global physics manager to update the timestep and those things

I'm doing something similar using bullet physics with my own rendering engine, I let the scene graph tie everything together so you get a clean engine architecture, and it creates the possibility of writing scene nodes and animators for any type of system you'd want in a game engine without having to mess with any other systems

Alpha Omega · Post by **Alpha Omega** » Sat Feb 12, 2011 7:57 pm

Well its been a month since I started this project and I have run into alot of unexpected things but I am starting to finally understand all the pieces. What I have built so far is a physics engine capable of object/object collision and object/world collision (this isn't totally viable yet). I havent optimized the collision detection yet, i am not sure if I should use BSP, or SAT, or some mix between a BSP and BVH. Anyway I am pretty much burnt out on this project I havent made any progress in about 3 weeks but if anyone is interested in me posting an alpha release I will consider or if you are interested on how to implement physics I can post my source as well.

If anyone is interested in helping me out with BSP, BVH, or SAT to optimize the collision detection or have any pointers on how to make my object/world detection and response viable for most games than I would be very pleased in any help on that.

stefbuet · Post by **stefbuet** » Sat Feb 12, 2011 9:32 pm

So what method did u use to calculate collisions impulses?

ChaiRuiPeng · Post by **ChaiRuiPeng** » Sun Feb 13, 2011 1:09 am

do not take sadness from your trials, remember as the great american inventor, mr edison, said: "i have not failed. i've just found 10,000 ways that won't work. "

Radikalizm · Post by **Radikalizm** » Sun Feb 13, 2011 1:29 am

Please do post the source, maybe someone can help with your work if you're actually burnt out, and it can always help others interested in physics engines

Alpha Omega · Post by **Alpha Omega** » Sun Feb 13, 2011 3:19 am

I posted the source under the download link on the OP

saltytaco1234 · Post by **saltytaco1234** » Sun Feb 13, 2011 4:56 pm

Wow i love it.

Alpha Omega · Post by **Alpha Omega** » Sun Feb 13, 2011 6:22 pm

How does the example run? I am kind of biased because I have a powerful machine so I dont know if theres lag for less powerful ones for that example.

REDDemon · Post by **REDDemon** » Mon Feb 14, 2011 9:23 am

The demo works as follow:
There are two blocks (O,X). You cann add gravitation force to one blocks or to the other one. H,F,T,G add more force to a sort of stack of forces. Z and X create a gravitation force around X or O blocks.

There are few issues.
1) Force is simulated by adding dv and dx or something similiar to node rotation and position. This is good only in few cases. If the timestep become to little you will suffer from rounding error troubles(or also if the force become to big). In that case items will start moving erratically sometimes but often the collision will make cubes gain escape speed and go very far in a little time.(that's physically not very probalbe and cannot certainly appens for all the cubes ) I had the same trouble in simulating a planet moving onto another planet using gravitation time ago. You must warn at least wich is the range in wich the force will work in a good way.

2)For doing correct gravitation simulation you need to use differential equation solvers or something similiar (runge kutta is an example). If not you need to avoid that by adding little fading to the motion. This will prevent cubes to escape from game as self-boosted rockets. I runned your demo also with a little force and it seems that cubes gain too much rotaion speed for the same reason of above.
For example I've seen a cube hitting the O block at slow speed starting rotating crazy.

3) gravitation need to be limited and applied only to bodies with a great radius. You must think instead of using a 1/R^2 proportional force, or applying a force making it going linearly when object is very near to gravity emitter. and linearly goin to zero when too far. (that's not realistic but can help a lot and in videogames you prefer a good looking solution instead of a physic realistic one... sometimes:) )

4) for pruning and spped up computation for gravity (wich is always expensive applying it to every object and for every gravity emitter , it is a good thing making a 3D tree (octree prefererred) in wich every child cube contain the sum of all gravity emitters in that portion of space, applying gravity to a body need only a interpolation betewwn 2 or 3 childs and can work well and at the same speed for N gravity emitters. (and octree can arrange child density due to the delta of the gravity field, wich is what i'm doing but in 2D in a space shooter game, with lot of thanks to Sudi)

the example is not very simple to understand, Actually your keys are triggering in a continuos way. So holding a key for a little while just make cubes going crazy in all ways. I suggest:

1) make the keys that influence motion of cubes "triggable" once. (WASD keys are setted correctly i can see, but other keys are not very userfriendly)

2) there are no terrains. just cubes and grey background. Add a terrain node or a plaing somewhere that help player to understand where he is. I see a grid scene node somewhere that is great for doing a squared plane.

3) always write on the screen some helps:
what the keys are doing, what is the purpose of the demo ecc.

Continue working on this. I like it much, have you thinked also to add 2D collisions?

I hope to not being to severe, but your project is good. Need just some more work

Alpha Omega · Post by **Alpha Omega** » Mon Feb 14, 2011 11:54 am

Yes I am thinking about going back and building in an ode solver with spring damping that should smooth out those kinks in the example. First though I am going to rewrite the obbox3d class to speed it up a bit and have a more exact collision detection method using the seperating axis theorem. Then I want to incorporate a BVH such as an octree. I understand how to do it in theory but haven't done it in person yet all I know it involves recursively subdividing space into 8 regions and making a grid out of it to check collisions for a great speed increase. Around that time I will have incorporated the ODE solver with spring damping which will then allow me to work on the contact equations and world collisions. At that time I will post a new release. Hopefully soon

Alpha Omega · Post by **Alpha Omega** » Tue Feb 15, 2011 3:20 am

I found some interesting news about obb collision detection. For some reason I thought that the seperating axis theorem on a obbox3d would run faster than an aabbox3d intersection test for course collisions. However after optimizing my code for the given example, including compiler optimizations, the abbox3d course collision test achieved a steady framerate of about 500 FPS, while the obbox3d course collision test achieved a steady 140 FPS.

This surprised me because I have read papers saying that the SAT is a very quick and efficient test, however the aabbox3d intersection test can run alot more efficiently by my example. Comparing the collision detection they are identical to the eye.

Also I must say that the fine collision detection is simply a face, vert intersection test for both cases. Apparently the false alarms that the aabbox3d flags just doesn't compare with the intensity of the SAT method.

Anyone have any experience and/or advice on what combinations to use for the most efficient detection?

On my way to Octree BVH