Novodex Physics Engine
novodex vs. newton
well, there is already some good wrappers written for irrlicht to work with newton, plus newton seems to have a somewhat more friendly license than novodex. on the other hand, the fact that its used by unreal IS very impressive, its like how the fact that HL2 uses havok lends some clout to that physics library. i think any physics library will require a good bit of tweaking to really work well. novodex's mesh deformation related features are impressive, newton AFAIK doesnt have that, just rigid-body physics.
for my purposes though in getting decent physics into my game engine, i think newton is the better fit....
2 main reasons, newton has already been shown to integrate well with irrlicht, and newton's structure makes more sense to me.
not saying i'm right or wrong, just my evaluation having used newton and checked out all of novodex's demos
for my purposes though in getting decent physics into my game engine, i think newton is the better fit....
2 main reasons, newton has already been shown to integrate well with irrlicht, and newton's structure makes more sense to me.
not saying i'm right or wrong, just my evaluation having used newton and checked out all of novodex's demos
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
Roberto...as in Roberto, the main coder of Newton?Anonymous wrote:...stuff about physics engines...
Roberto
I like Newton, I really do, but you (purposely) sacrifice speed for accuracy and stability. Unfortunately, for a lot of people, that's an unacceptable trade off. Both the Newton and Novodex APIs are gorgeous to work with, but they have different goals in mind. And choosing between the two is finally dictated by which is more important to you -- speed, or accuracy. I know, for exaple, that Newton can switch to soft body simulation when dealing with masses with very large differences in mass. That's just plain slick. But it hurts my poor CPU, and I can't afford it, unfortunately.
well, philosphically...
i dunno, but coming from a administration background, i dont care how fast it is, if it could be more stable or more accurate, I'd say OK.
its a philosophical choice really, given the old 3 choices inherent in all engineering projects...
cheap, fast, and good, pick 2.
given that choice, i always choose cheap and good...what's the point of it bein fast if it either isnt right, or it costs too much. given that we are talking about 2 free(mostly) physics engines, cost really doesnt enter into it here, and we have a choice of fast or good. still, i choose GOOD.
however, I know i certainly don't speak for everybody. I know a lot of people feel that if it is too slow or doesnt run on older hardware it is of no use to them.
but to me, the hardware merely enables the software, hence i make my choice without viewing it as a limiting factor.
I know that in my own code i frequently and up sacrificing speed for the sake of cleanliness or clarity.
I guess its the systems administration background, but really, who wants a game that crashes all the time?? and what programmer wants to maintain code that is impossible to read??
heh...maybe it's just me...
its a philosophical choice really, given the old 3 choices inherent in all engineering projects...
cheap, fast, and good, pick 2.
given that choice, i always choose cheap and good...what's the point of it bein fast if it either isnt right, or it costs too much. given that we are talking about 2 free(mostly) physics engines, cost really doesnt enter into it here, and we have a choice of fast or good. still, i choose GOOD.
however, I know i certainly don't speak for everybody. I know a lot of people feel that if it is too slow or doesnt run on older hardware it is of no use to them.
but to me, the hardware merely enables the software, hence i make my choice without viewing it as a limiting factor.
I know that in my own code i frequently and up sacrificing speed for the sake of cleanliness or clarity.
I guess its the systems administration background, but really, who wants a game that crashes all the time?? and what programmer wants to maintain code that is impossible to read??
heh...maybe it's just me...
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
I agree with you buhatkj. Admittedly I haven't really used any physics engine other than Newton (looked at Tokomak once, but their docs were gibberish), so mine is not a completely objective and experienced opinion. Simulating physics in realtime is hard to do with perfect accuracy. Even Newton isn't completely realistic all the time. I'd hate to be using an engine less acurate than newton. If one gets physics anomolies all the time it's impossible to tell whether your coding is buggy or if it's the engine. I personally don't really have much of a problem with newton's speed. It seems quite fast with a small number of collisions. Even a fairly large number of collisions is generally handled well. See their block tower demo. It runs smoothly and shows no visible change when autosleep is switched on or off. The only time I have problems with speed is in Mercior's block demo if I just keep shooting 50+ blocks all on top of eachother. In most game physics situations you aren't likely to have that many things all colliding together at the same time. I believe Newton's solver is quadratic at it's heart, so more collisions in one place will exponentially increase solver time, but for most realistic simulations it's fine. I'm running a P4 2.8 GHz which, while not absolute top of the line these days, is not too old and slow. Maybe Newton causes more of a problem for people with slow processors, but I haven't really had a speed problem.
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
Less accurate doesn't mean worse looking, or obviously wrong. It means that the engine will skip doing the complete set of solutions (which are, according to the ODE docs, O(m*n), or roughly quadratic) and instead choose cheap approximations. In many cases, it will be wrong, but it will still look good.
I'm running an Athlon 1.3, which really drives the speed point home.
I'm running an Athlon 1.3, which really drives the speed point home.
I currently take a look at some physics engines available to find out which fits best my needs, but I have a problem with this one:
Novodex and Irrlicht are using different data types for transformation matrices. While in Irrlicht it is a 4x4 matrix in Novodex it is a 3x4 matrix. Has anyone an idea how to convert them into eachother?
Novodex and Irrlicht are using different data types for transformation matrices. While in Irrlicht it is a 4x4 matrix in Novodex it is a 3x4 matrix. Has anyone an idea how to convert them into eachother?
YASS - Yet Another Space Shooter - www.yass-engine.de
i read on the newton forum that the newton solver will soon support 3 modes.
exact - this is the mode which gets used in the current newton version
adaptive - i guess the solver does something inbetween exact and linear depending on the situation
linear - i guess this means that it is O(n)
so the user will be able to decide if he wants accuracy / stability or speed.
exact - this is the mode which gets used in the current newton version
adaptive - i guess the solver does something inbetween exact and linear depending on the situation
linear - i guess this means that it is O(n)
so the user will be able to decide if he wants accuracy / stability or speed.
I managed to convert the transformation matrices into eachother and it seems to work, though I only tested it from 3x4 to 4x4. The other way round should work also, at most there could be a typing error. I really do not know if this approach is efficiently written, but maybe someone is interested in it though...
Code: Select all
NxMat34 CPhysicsManager::convertMatrix(irr::core::matrix4 * IrrMat)
{
NxMat34 NxMat;
// fill in 3x3 rotation matrix
float row[3];
for(int i = 0; i < 3; i++)
{
for(int j = 0; j < 3; j++)
{
row[j] = IrrMat->M[i*4 + j];
}
NxMat.M.setRow(i, row);
}
// fill in position vector
irr::core::vector3df pos = IrrMat->getTranslation();
NxVec3 Nxpos(pos.X, pos.Y, pos.Z);
NxMat.t = Nxpos;
return NxMat;
}
irr::core::matrix4 CPhysicsManager::convertMatrix(NxMat34 * NxMat)
{
irr::core::matrix4 IrrMat;
// fill in 3x3 rotation matrix
NxVec3 row;
for(int i = 0; i < 3; i++)
{
row = NxMat->M.getRow(i);
IrrMat.M[i*4] = row.x;
IrrMat.M[i*4 + 1] = row.y;
IrrMat.M[i*4 + 2] = row.z;
}
// fill in position vector
NxVec3 Nxpos = NxMat->t;
IrrMat.M[12] = Nxpos.x;
IrrMat.M[13] = Nxpos.y;
IrrMat.M[14] = Nxpos.z;
// fill in 4th column
IrrMat.M[3] = 0;
IrrMat.M[7] = 0;
IrrMat.M[11] = 0;
IrrMat.M[15] = 1;
return IrrMat;
}
YASS - Yet Another Space Shooter - www.yass-engine.de
After I got the Novodex Debug Renderer working with Irrlicht, I noticed that the scene node rotated in exactly the opposite direction in which it should. So, for the case someone ever will use my code here is it again with a little bugfix:
Btw, now after I tested both Novodex and Newton, I think Novodex can handle a lot more dynamic objects than Newton, Novodex's performance is great. But before I will make my final decision I keep on testing a while...
Code: Select all
NxMat34 CPhysicsManager::convertMatrix(irr::core::matrix4 * IrrMat)
{
NxMat34 NxMat;
// fill in 3x3 rotation matrix
float row[3];
for(int i = 0; i < 3; i++)
{
for(int j = 0; j < 3; j++)
{
row[j] = IrrMat->M[i + j*4];
}
NxMat.M.setRow(i, row);
}
// fill in position vector
irr::core::vector3df pos = IrrMat->getTranslation();
NxVec3 Nxpos(pos.X, pos.Y, pos.Z);
NxMat.t = Nxpos;
return NxMat;
}
irr::core::matrix4 CPhysicsManager::convertMatrix(NxMat34 * NxMat)
{
irr::core::matrix4 IrrMat;
// fill in 3x3 rotation matrix
NxVec3 row;
for(int i = 0; i < 3; i++)
{
row = NxMat->M.getRow(i);
IrrMat.M[i] = row.x;
IrrMat.M[i + 4] = row.y;
IrrMat.M[i + 8] = row.z;
}
// fill in position vector
NxVec3 Nxpos = NxMat->t;
IrrMat.M[12] = Nxpos.x;
IrrMat.M[13] = Nxpos.y;
IrrMat.M[14] = Nxpos.z;
return IrrMat;
}
YASS - Yet Another Space Shooter - www.yass-engine.de