Irrlicht Engine

I've come to the point where I can no longer put off adding physics to my game engine, and the bullet wrappers look good.

I'm just wondering, what's the difference between them, and which one should I use?

what are some of the most essential things your game is going to need?

It's more of an engine, so it would have to support several high level features while allowing easy extendability.

Features I can think of off the top of my head that I would really like to have built in and easy to use:

* Soft Body

* Rigid Body

* Ragdoll physics

* Water body

* Vehicle physics

* Gravity

* Collision detection

* Ray tracing

* Easily available through C++ not requiring any specific editors like coppercube or IrrEdit

I know some of these things are available already in Irrlicht, but I'm assuming that they are handled better by a dedicated engine. I think if I'm going to use a physics engine, I should use if for all physics.

Thanks!

then why go through a wrapper? just get unaltered copy of latest bullet and build your engine around that.

using a wrapper can save lot of time, but it will never be the exactly you need/want.

Does bullet really do all that without a lot of hassle trying to gather the features together and get them working?

Bullet is a Collision Detection and Rigid Body Dynamics Library.

I just kind of assumed Irrlicht integration and higher level stuff like water and soft body etc, would be a big long thing to setup. I would prefer something where I don't have to worry about integration and making feature X or Y cooperate.

I'm just afraid that if I do it myself I'll be reinventing a wheel that has already been invented more than once. Then I'll post mine, and there will be three wrappers to choose from.

I guess it's probably only a matter of time before my programmers instinct kicks in and I become convinced that I need to write my own physics engine from scratch.

For now, I'm willing to lose some flexibilty to ease of use. I guess I should probably try out both and pick one for myself.

Dareltibus wrote:using a wrapper can save lot of time, but it will never be the exactly you need/want.

well yes, but he wants an engine, if i were writing a game engine i would want the best performance and most features. writing your own middleware will make sure you are familiar with the intimacies of how your engine works. adding external wrappers or external facade type middleware might introduce more dependencies than you need.

I've tried both, and I can say that writing your own is better, just because you control how things go in it.

I'm just afraid that if I do it myself I'll be reinventing a wheel that has already been invented more than once. Then I'll post mine, and there will be three wrappers to choose from.

I guess it's probably only a matter of time before my programmers instinct kicks in and I become convinced that I need to write my own physics engine from scratch.

You might reinvent it, though I don't think that it will be the same as the two others mentioned, yours will suit your needs better.

Though If you write your own wrapper you shouldn't integrate it into your framework until it really works good (no memory leaks, bugs).

I've written my own bullet "wrapper", though its a lot smaller, and it doesn't really wrap much, as I still have to deal with regular bullets objects once they get created (btRigidBody,btSoftBody). Though that way I can get all the control I need, without using what the other wrappers above mentioned do ( body->getBodyPtr() ), if I'm correct.

why don't take the chanche for write a fully abstracted physics engine? I had this idea some time ago but i don't have any time for doing that.

After that someone need only to write a driver for bullet, a driver for ODE etc..

I like that idea, but I just remembered that there is something like that...
Ah yes, PAL: http://www.adrianboeing.com/pal/index.html

Any of you ever give PAL a spin? Maybe I should probably try it. Bullet seems to have a lot of examples under it's belt. But I haven't heard of PAL as much.

REDDemon wrote:why don't take the chanche for write a fully abstracted physics engine? I had this idea some time ago but i don't have any time for doing that.

After that someone need only to write a driver for bullet, a driver for ODE etc..

I don't think anyone really needs an "abstracted physics engine" as you mainly focus and configure one, that fits you needs.
Maybe it could only come in handy when testing which one to choose, but I've already chosen mine

I am thinking about a framework that just posts events whenever something happened that needs a world update. I think that it won't make any (or much) difference if the message came from another physics engine. I hope that I find time and motivation to do that, but summer's about to start so I do (at the moment) not turn on my computer at home that often.

lazerblade wrote:....

Features I can think of off the top of my head that I would really like to have built in and easy to use:

* Soft Body

* Rigid Body

* Ragdoll physics

* Water body

* Vehicle physics

* Gravity

* Collision detection

* Ray tracing

* Easily available through C++ not requiring any specific editors like coppercube or IrrEdit
.....

Great dreams! It seems to me you will be write this engine 10 years, not less
I think you need to concretize the purposes.

Morganolla wrote: Great dreams! It seems to me you will be write this engine 10 years, not less
I think you need to concretize the purposes.

Seeing as his initial post stated he wants to use bullet which has all of these features already implemented this will not take him 10 years. Please read everything posted before making such remarks in the future.

I also would suggest not using a wrapper. Bullet itself is not very difficult to handle the only thing you may want to borrow from one of the wrappers is how they use motion states and their debug drawers. These aren't very hard to do yourself but might as well use what is already available. The rest of bullet is fairly simple to create and utilize completely. I haven't used vehicle things but there are demos available for each thing you want to create and use. I am sure you won't have any trouble integrating bullet directly once you understand the demos and how things work in it. I myself even threaded bullet off so it can simulate at a constant pace and keep Irrlicht up to date with the motion states.

EDIT: made my post less offensive and more positive.