Version 0.1 Alpha Release: Irrlicht Dedicated Physics Engine

Alpha Omega · Post by **Alpha Omega** » Sun Jan 09, 2011 11:24 pm

Hello everyone! I am pleased to announce my current project I am working on. I am creating a physics engine dedicated soley for Irrlicht applications! I must say that after several attempts to use built in Irrlicht physics and failing to apply big bulky physics engines, I finally made the decision to create a new physics engine for the Irrlicht community!

This is good for developers that just need the "basic" physics in Irrlicht for there games. The code is so easy to integrate when compared with big bulky physics engines and coding with ISceneNodeCollisionResponseAnimators.

Engine in Action

No Gravity Collisions Test With OBB Volumes
http://www.youtube.com/watch?v=3WUkEF3mtLw

Physics Stress Test 1 NEW!!!!
http://www.youtube.com/watch?v=IdUymohMIS0

Tornado/Gravitation Physics Stress Test NEW!!!!
http://www.youtube.com/watch?v=_Cdx2GFDFsg

Download V 0.1 Alpha Release

http://www.mediafire.com/?sah6avpvb92w3i4

The full library plus a main.cpp demo. That utilizes a gravity transform. Press X or Z for a gravity transform of each cube with 100 sub objects in scene. WASD for camera movement.

Features!

---Extremely easy integration into Irrlicht Applications
---A wide array of functions that can be used by more experienced in the API.
---No collision Animators!
---Three lines of code can install physics into your project!
---Very good collision response and physics for the code you have to write!
---Currently using bounding boxes to apply physics but will use TriangleSelectors in time.

Integration

So far you only have to right three lines of code to incorporate physics and collision detection into your Irrlicht App.

Code: Select all

PhysManager* pmgr = new PhysManager;

// create physics manager

Code: Select all

PhysObj* PhysicsObject = pmgr->addPhysObjToQueue(smgr,"meshfilename.obj",mass);

// create PhysObj pointer and initialize all Irrlicht pointers as part of the PhysObj class while adding all PhysObj objects to the physics stack

[/code]

Code: Select all


updateScene(pmgr,frameDeltaTime);


//Update the Scene

[/url]

Radikalizm · Post by **Radikalizm** » Sun Jan 09, 2011 11:54 pm

Sounds interesting, do you already have some actual physics code up and running?

Building a correct physics model from the ground up can be pain in the ass, that's why almost all game programmers, commercial studios and hobbyists alike, use middleware packages to get physics in their games

But if you're really dedicated and if you really want to do this, all I can say is good luck!

Alpha Omega · Post by **Alpha Omega** » Mon Jan 10, 2011 12:12 am

Yes quite a deal of code has already been written. Right now Collisions, Position Transformations, Forces, Velocities are fully operational with a very nice physics object manager that is designed to fit with irrlicht. The collisions are very nice I have to say, sometimes the speed of the objects moving causes problems but I havent had an issue with collision detection yet.

Radikalizm · Post by **Radikalizm** » Mon Jan 10, 2011 12:18 am

Alpha Omega wrote:Yes quite a deal of code has already been written. Right now Collisions, Position Transformations, Forces, Velocities are fully operational with a very nice physics object manager that is designed to fit with irrlicht. The collisions are very nice I have to say, sometimes the speed of the objects moving causes problems but I havent had an issue with collision detection yet.

Would it in any way be possible to show some simple footage of the engine in action, like cube on cube collision?

It would be nice to have a very basic set of extended irrlicht features (a framework) which could be maintained in a separate project seeing as a lot of people use irrlicht for simple simulations and experiments
This would save the hassle of implementing advanced systems for simple simulations

macron12388 · Post by **macron12388** » Mon Jan 10, 2011 12:27 am

Does it use a fully independent [from Irrlicht graphics rendering/frame rate independent] time step frequency?

Alpha Omega · Post by **Alpha Omega** » Mon Jan 10, 2011 12:52 am

Radikalizm wrote:
Would it in any way be possible to show some simple footage of the engine in action, like cube on cube collision?

I posted a Link at the top of the page. I havent implemented gravity simply because I havent written the floor class code but once I have written that I will compile with gravity and have the blocks jump around.

The visualization is in 2D but the engine calculates in 3D I just had the Z axis fixed for that demo.

Not amazing but soon there will some more this is just showing off the collisions. Notice in the command panel that the blocks only collide once and not a billion times. See the same video using Irrlicht functions below the first link

.

Alpha Omega · Post by **Alpha Omega** » Mon Jan 10, 2011 12:56 am

macron12388 wrote:Does it use a fully independent [from Irrlicht graphics rendering/frame rate independent] time step frequency?

No it uses the same as Irrlicht. This makes it less confusing. You set when you want Irrlicht to render and then just call updateScene(); next to smgr->drawAll();

I prefer this because there is less guess work. Another way to say it is it the physics engine will adapt to Irrlicht. If Irrlicht wants to run at this speed than the Engine will adapt. Its quite useful.

shadowslair · Post by **shadowslair** » Mon Jan 10, 2011 3:19 pm

Well, I`m sure your project is still in very early phase, but what the "engine in action" does currently is 1 dimensional discrete collision between two AABBs with quite unreallistic impulse behaviour, which can be done in less than 15 minutes. Creating a robust sytem is quite hard, unless you`ve studied physics and maths seriously and the way the simplified physics models are applied in graphics apps. Of course such a lack of knowledge can be satisfied by maybe 1-3 months reading of very uncolourful books, filled with sanscrit symbols. I don`t say it`s impossible, but it`s definitely not for everyone. Surely, playing with "physics" at such low level is fun, but with time things will become different...

devsh · Post by **devsh** » Mon Jan 10, 2011 5:16 pm

I will bow down and kiss your feet if you implement DMM!!!

stefbuet · Post by **stefbuet** » Mon Jan 10, 2011 7:38 pm

I'm very interested in your work.
I'm currently working on a basic 3D physic engine handling spheres and fixed planes as a student project. Balls will be able to collide with each other and with planes too. I'm still studiing impulsive reactions beetween bodies and I'm pretty sure I'll go with the Routh's graphical method which takes care of compression and restitution phases, however if I could get some code from other people to see the way they are doing it would be great. Also for now Idk if I gonna choose Runge Kutta integrator (order4) or Verlet integrator in case of a need to add some springs, else I guess using the basic acceleration integration will be fine. By the way, in fully interested by anything you will produce concerning physic.
Thanks and good luck

Alpha Omega · Post by **Alpha Omega** » Tue Jan 11, 2011 12:57 am

stefbuet wrote:I'm very interested in your work.
I'm currently working on a basic 3D physic engine handling spheres and fixed planes as a student project. Balls will be able to collide with each other and with planes too. I'm still studiing impulsive reactions beetween bodies and I'm pretty sure I'll go with the Routh's graphical method which takes care of compression and restitution phases, however if I could get some code from other people to see the way they are doing it would be great. Also for now Idk if I gonna choose Runge Kutta integrator (order4) or Verlet integrator in case of a need to add some springs, else I guess using the basic acceleration integration will be fine. By the way, in fully interested by anything you will produce concerning physic.
Thanks and good luck

If I am going to solve any ODE's I am going to try to use Laplace Transforms since they are very easy and can give exact solutions. Plus impulse forces can be simulated with a thing called the dirac delta function. Anyway right now I am just coding a simple classical physical approach based on energy conservation. Physics engines use the impulse method because rotational transforms get really nasty if you keep using energy conservation theorems. (I think it hasnt been reliably down because of the lag factor).

Alpha Omega · Post by **Alpha Omega** » Tue Jan 11, 2011 12:59 am

shadowslair wrote:"engine in action" does currently is 1 dimensional discrete collision between two AABBs with quite unreallistic impulse behaviour

Wrong the engine is fully functional in 3 dimensional translation. Also the method is not based on impulse but elastic momentum conservation. I only put up the video because it was an irrlicht requirement and someone asked. If you have any constructive ideas I would be very interested in hearing them.

Updated vid with gravity test.

Luben · Post by **Luben** » Tue Jan 11, 2011 2:11 am

[Thread hijacking in progress]
You guys wouldn't have any links and/or papers lying around about implementing physic engines? =]
I've been wondering for a while how the theory behind them works and i'd be delighted if you could provide me with some interesting pointers ;]

Radikalizm · Post by **Radikalizm** » Tue Jan 11, 2011 9:34 am

Luben wrote:[Thread hijacking in progress]
You guys wouldn't have any links and/or papers lying around about implementing physic engines? =]
I've been wondering for a while how the theory behind them works and i'd be delighted if you could provide me with some interesting pointers ;]

I think the best way to grasp the concepts of a physics engine is just taking a course of advanced physics (or do a lot of research about it) and go on from there

From a design/architectural point of view I don't think that physics engines are extremely difficult to build (I could be horribly wrong, since I've never actually written a complete engine, just some small simulations for my engineering mechanics course), it's just the theory behind them that makes it difficult to implement, together with finding real-time optimizations since most theorems will not be suited for on-the-fly calculations

Alpha Omega · Post by **Alpha Omega** » Tue Jan 11, 2011 1:40 pm

Radikalizm wrote:
I think the best way to grasp the concepts of a physics engine is just taking a course of advanced physics (or do a lot of research about it) and go on from there

From a design/architectural point of view I don't think that physics engines are extremely difficult to build (I could be horribly wrong, since I've never actually written a complete engine, just some small simulations for my engineering mechanics course), it's just the theory behind them that makes it difficult to implement, together with finding real-time optimizations since most theorems will not be suited for on-the-fly calculations

Actually applying equations of motion is the easy part. most physics engines apply a posteriori or discrete method to handle collisions. A posteriori engine works by involving a time step and analyzing objects on each time step. This leads to having to approximate the equations since the time interval is not continuous. A priori engine calculates collisions before they occur and thus for games would be extremely laggy since the engine would attempt to solve alot of PDE's to describe particles in motion.

The most robust part of the engine is not what you see on the surface but how you manage applying physics to all of your objects. My physics engine uses a manager class to check collisions of objects with each other. There are several pruning techniques to check for collisions such as using AABB boxes as an initial check. More advanced checks will need to be determined by checking for triangle intersections which are extremely costly in terms of computing power. Once you have all objects that are colliding you apply the equations of motion to those objects.

Putting it on a quantified level my manager class is over 500 lines of code where as Newton's second law takes up 50 lines.

My engine will attempt to apply a posteriori approach with priori compensation which using process control theory is the most stable control system that exists (I am a chemical engineer so sorry for the vocabulary).