Irrlicht Engine

irrSimplePhysics v0.002
(on 3 Feb 2009)


Examples:

v0.001, Example: prelimary Proof-Of-Concept demonstrating how SceneNodes can be applied forces for relatively realistic physics-behaviour. In a simple way.

v0.002, Example 2: a simple "flying-peach" node controller. Move it around and make it "jump"


Screens:

A screenie: (doesn't do it justice, you can't see the motion involved)


Screenie from irrSimplePhysics Example 2 [v0.002]:

(beware the flying peach! )


I created this for all those people using Irrlicht who want "some" basic physics going on, but don't want to go through the hassle of integrating a full-blown physics engine into their projects.
Allows any Irrlicht SceneNode to be treated with more realistic Physics behaviour, applying gravity, forces and velocities if the user wishes.

Its now just a simple class that you throw your SceneNode at and it handles all the maths. It has to be updated each frame though (see the source for more info).

Currently only handles basic linear Forces and Velocities (its possible to achieve some interesting effects like projectiles and force-fields accuratly enough).

Don't expect to see any Torques or Angular-Velocities anytime soon (far too complicated and demanding, just use a real physics-engine!).
Collision-detection is certainly an option though.

I forgot to mention in the README, but you should use "real-world" numbers for inputs (as you should all know by now):
- Mass = KG
- unit-dimensions / positions / scales = Metres
- Force = Newton (1 KG moving 1 M)
- Time = seconds
- Velocity = M/sec

(can I just add - this is by no means a replacement for ANY real physics-engine, and I'd recommend using a real one over this wherever possible)

Source and Example:

irrSimplePhysics v0.001: http://www.mediafire.com/?muwyzkftggk
irrSimplePhysics v0.002: http://www.mediafire.com/?mxyyy3tthhi (LATEST VERSION)

TODO:
- Simple SceneNode ANIMATOR too
- "simple" collision-response for Irrlicht collisions


Give it a whirl and see what you make of it.
Contributions, tips, opinions, criticisims, all welcome.

"may the farce be with you"

A sceneNode? Why not make an affector?

Demo looks nice, if you implement the Memory-Cleanup I consider using it for my Game.

That's pretty neat, keep it up

Dorth wrote:A sceneNode? Why not make an affector?

i second that

I should have thought it out / discussed this a little more before getting started on it, but what the heck.

thanks for your opinions guys.

The reason its not an Affector is because stuff like Collision-Detection and other Global-physics attrbutes (eg, scaling, gravity, etc) simply wouldn't work, and trying to modify or edit forces/velocities on already affected objects really would not be very easy.

But I agree, a SceneNode is really quite "ugly" in this kind of situation, and I'll just make a regular class out of it instead.

The idea with this is NOT to ever become a core part of Irrlicht, and because I'm trying to encourage people to use REAL Physics-Engine's instead of this, I've intentionally designed it similar to how the wrappers sort-of work.

It won't be "nice and easy", but it will be "nice and simple".

And I guess I need a new demo - this one makes it appear as though its only good for particles (hence the affector-style assumption) but its a lot more than that, and is intended to allow controllable physics for Characters and Vehicles too.

Update coming soon

I'd like to see some kind of explosion in your demo where meshes burst away etc.

Great! I'll try it. Thanks!

Oooo, looks nice

I've had a long long think about this project, and I'm beginning to wonder how much future it has.

TBH I don't care if people don't ever switch to real Physics-API's for simplistic Physics needs, this project fulfills the basic needs and it shouldn't be expected to do anything more.

The idea of simply making affectors out of this doesn't sound too bad at all now, because it would give people what they want (simple Physics behaviour without a Physics-Engine) and i wouldn't have to TRY make a physics-engine out of it (consider how little it really would be capable of)

So what do YOU guys think?

- Keep it the way it is: a "baby"-physics engine minus all the cool features (will stop being updated after a while, can't dedicate my time on it forever)
(oh, and NOT as a scene-node, but as a class of its own)

- Affectors: Simplicity and ease of Irrlicht with a simple affector-class
(wont be anything like how Physics-API wrappers tend to work, maybe not even as accurate or useful)

- something else altogether?

I'll update the project over the weekend, making it practical enough to use as it stands, but its future remains uncertain.
It might change altogether (and become a Code-Snippet rather than a Project), just have to wait and see

Hi, very interesting fmx!

In CirrPhysicsObject::reset() shouldn't there be node->remove(); just before node = 0; ? Or addToDeletionQueue();

I would have just created a single scene node with calculations inside and let the user manage his arrays of objects. This lets the user free to derive the class and adjust the code to create say a bullet or a grenade. For now there are S3DVertex in the objects manager but not in the PhysicsObject, strange ...

Also why not create a drawAll() method for your objectsManager and put the code from the main loop inside.

Important is to add a terrain.

Good job. After some improvements one will talk about a physics engine.

fmx wrote:So what do YOU guys think?

- Keep it the way it is: a "baby"-physics engine minus all the cool features (will stop being updated after a while, can't dedicate my time on it forever)
(oh, and NOT as a scene-node, but as a class of its own)

- Affectors: Simplicity and ease of Irrlicht with a simple affector-class
(wont be anything like how Physics-API wrappers tend to work, maybe not even as accurate or useful)

- something else altogether?

I'll update the project over the weekend, making it practical enough to use as it stands, but its future remains uncertain.
It might change altogether (and become a Code-Snippet rather than a Project), just have to wait and see

Whichever is easiest for people to use. :3

I think that's what he wants to do... find out what's easiest for people... He's asking which it is

personally i think it would be really good if it was easy to use, but also prepared people for real physics engine. this way one can play around, and understand the concepts involved when implementing real physics engine support.

I would say switch to affector. That will fit better in to Irrlicht structure and will be much more useful and logical. You want your node to be affected by simple physic? ...just create simple physic affector and you are good to go.

Nodes do lot of stuff which is related to rendering/registering and such and which you want to avoid. It probably can even slow things a little bit. On the other hand affector fits role perfectly.

Also if you can put in collision detection it would be very nice project. Some effective collision detection I must say, not one which will test all polygoons on all objects at the same time.