Does anyone have any numbers showing exactly how much faster various physics engines are compared to Irrlicht and each other?
Has anyone compiled any of these other engines into a DLL that allows us to easily replace the Irrlicht collision checking with them instead? Same names for functions, and look there first, or similar name us just having to find each place a command was called and adding a letter to the function name to check for Newton/etc. instead?
comparing physics engines versus Irrlicht for collisions
-
Wolf Dreamer
- Posts: 121
- Joined: Tue Feb 10, 2004 6:39 am
- Location: the land of chaotic dreams
- Contact:
comparing physics engines versus Irrlicht for collisions
The last sane human being in a world gone mad
http://s8.invisionfree.com/Game_Maker_f ... hp?act=idx
http://s8.invisionfree.com/Game_Maker_f ... hp?act=idx
10 - 6??? 
You have to integrate the physics in to Irrlicht, I don't think it would be beneficial to compile the two together, creating a wrapper yes. But compiling both together for a dll probably isn't allowed. In fact I don't think you can have access to Newton and recompile so no its not been done. There is a wrapper though on the projects page Irrlicht + Newton == Irrlicht++ or something like this...
Keeping them seperate the graphics and the physics engine would allow portability as well, remember you might not always Irrlicht and a physics engine together...
You have to integrate the physics in to Irrlicht, I don't think it would be beneficial to compile the two together, creating a wrapper yes. But compiling both together for a dll probably isn't allowed. In fact I don't think you can have access to Newton and recompile so no its not been done. There is a wrapper though on the projects page Irrlicht + Newton == Irrlicht++ or something like this...
Keeping them seperate the graphics and the physics engine would allow portability as well, remember you might not always Irrlicht and a physics engine together...
collisions between the 2 are not the same, and if they were, it wouldnt be physics. even if they were compiled together, they both wouldnt make the same calls to the same classes, so it would be like 2 dlls in one, and the only trouble it saves u is not linking the second. so whats the point?
btw, its newton++ http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5648
btw, its newton++ http://irrlicht.sourceforge.net/phpBB2/ ... php?t=5648
-
cmoibenlepro
- Posts: 237
- Joined: Thu May 27, 2004 3:18 pm
- Location: Canada
Irrlicht collision animator can be improved like basic physics collision animator. It's not a big problem to implement some Newton functions from physics books. But if you need any advanced physic engine ODE or Newton are the choice.
Site development -Rock and metal online
--- etcaptor.com ------freenetlife.com
True Axis and Novodex are getting some attention lately too. I haven't tried either one, though one thing that impressed me about the True Axis demos was its ability to handle small, fast objects
You do a lot of programming? Really? I try to get some in, but the debugging keeps me pretty busy.
Crucible of Stars
Crucible of Stars
ODE...
True, ODE is the only physics package I am aware of that is truly Open Source. Hence it would be the only one we would have a shot at integrating with Irrlicht (whether we would even WANT to do that is another issue entirely...)
However, ODE does not (c'mon, admit it!) have the greatest interface in the world. Compared to ODE using Newton is a breeze. That isn't to say that we might not easily wrap ODE in such a way that it was just as easy to use as Irrlicht, I'm just saying that as far as I know it has not been done YET.
For the basic irrlicht user the best situation would be a generic physics animator which uses (in it's most simple form) the bounding box of the node (for animatedmesh) or the actual triangles (in the case of an octtree) to determine the proper response to collision. This would require significant additions to irrlicht's materials system to support physics properties as part of materials settings and in the interest or working with different licencing issues we would want to be able to use a common interface to the various underlying physics packages that provided the actual physics math and so forth. Something like this was attempted for the ROCKET physics scripting language thinger that uses novodex. (they intend to add support for other physics engines at some point...)
In my work on FNORD, I am trying to write a layer above irrlicht's material/textures to contain the physics properties of that fgiven material as well, and at some point I will get around to actually making newton work lol
However, ODE does not (c'mon, admit it!) have the greatest interface in the world. Compared to ODE using Newton is a breeze. That isn't to say that we might not easily wrap ODE in such a way that it was just as easy to use as Irrlicht, I'm just saying that as far as I know it has not been done YET.
For the basic irrlicht user the best situation would be a generic physics animator which uses (in it's most simple form) the bounding box of the node (for animatedmesh) or the actual triangles (in the case of an octtree) to determine the proper response to collision. This would require significant additions to irrlicht's materials system to support physics properties as part of materials settings and in the interest or working with different licencing issues we would want to be able to use a common interface to the various underlying physics packages that provided the actual physics math and so forth. Something like this was attempted for the ROCKET physics scripting language thinger that uses novodex. (they intend to add support for other physics engines at some point...)
In my work on FNORD, I am trying to write a layer above irrlicht's material/textures to contain the physics properties of that fgiven material as well, and at some point I will get around to actually making newton work lol
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net