Newton or ODE?

[Guest]

OK, I think there are two things here that need to be cleared up.

Firstly, ODE is a simulation engine first whereas Newton is a game-engine first. As such, there are features which are not included "by default" in ODE that are included in Newton. However, a very quick search on Google shows that all the features touted by the Newton engine can be done within ODE with comparable (and often better) stability. The "auto-sleep" feature has been described & improved on many times in the ODE user list, and has been used in several games (the most recent of which, in my memory, was BloodRayne 2).

Well I think you are right, some clarification is needed. First I must say I do not have the qualifications to determine what makes one engine "a simulation engine first” and the other a “game-engine”, but I do not think the name of the product would be the deciding factor. For what I can see with my own experimention Newton is closer to a realistic simulator than any other engine I tried (I only tested the free engines).

What I do not really understand is it how it is that for ODE users anyone using Newton is because is an idiot that do not understand how physics works. I was an ODE user for a long time before I started experimenting with Tokamak and Newton. I could never figured out the proper values of CFM and ERP, and the way I see it is the same for many people.

ODE vs Newton - Pure Collision System: I fail to see how this makes one a better PHYSICS engine than the other. Collision engines are a dime a dozen, alot of them licensed under lenient terms (such as the MIT & BSD licenses). And to be honest, I cannot see the NEED for a cone primitive, though if it were necessary - it would be a half a days work to implement. It is (after all) a quadratic just like cylinders & spheres - which makes them simple mathematically speaking.

By the same token I fail to see how not having these features make ODE a "Simulation engine" and Newton a "Game engine" the implication being that ODE is for more advance people. I do not think that the cone collision is as simple as you try to imply, if it was then cylinders that are even simpler would be working in ODE, they aren't.
It is also worth noticing that it is not only cones, Newton also has other collision primitives. Maybe for you having optimized mesh collision, convex hulls, many collision primitives, closest distance calculation, collision scale, etc. are trivialities that do not contribute anything to a physics engine, I just find them a nice feature to have.

ODE vs Newton - 'Ultimate Flexibility': I'm not sure where this comes from, but being able to change anything in the source code makes ODE the "ultimate in flexibility" from my point of view. While Newton allows me to create new joint types - ODE allows me to tweak the underpinning mathematics. While I don't think doing so is a good idea for the average game developer - the ability to do so offers more flexibility than Newton can. The example of being able to write your own joint types has already been shown to be possible with ODE (in my last post no less *laugh*)

As for the comment on ODE being badly designed because it allows someone to implement a new joint type - I REALLY cannot understand that. Being able to implement & extend a library without problems is generally a sign of GOOD design. I would love to hear why you classify it as bad...

I remember when the Newton came out, it was dismissed because it did not have enough features, now it is dismissed because it has too many features. Perhaps you are above the average game developer and you can tweak the “underpinning mathematiocs” of ODE, if so more power to you.
For me I do not want to do that, the way I see changing a joint from a hinge to a point to point to simulated damage is the kind of tweak I am interesting in doing. Manipulating the contact friction to simulate a conveyor belt is also the kind of tweaking I like to do.

On the other hand changing the CFM and ERP indefinitely to get the auto sleep to kick in or to make joint not to explode, might be an advance feature of ODE, but let me tell you I got tire of that.

The bottom line is that trivializing the features and saying that you can add them to ODE in a couple of days does not make it a fact, and until that happens your claim that there is not much difference between them is simple not truth.

[Eternl Knight]

Well I think you are right, some clarification is needed. First I must say I do not have the qualifications to determine what makes one engine "a simulation engine first” and the other a “game-engine”, but I do not think the name of the product would be the deciding factor. For what I can see with my own experimention Newton is closer to a realistic simulator than any other engine I tried (I only tested the free engines).

Well, I would agree with you on that. Not EVERYTHING is about a name. However, it IS called "Newton Game Dynamics". I don't think it takes a brain surgeon to work out what they are aiming for. I also mentioned other methods of telling the two apart in that context (i.e. the users frequenting the forums/mailing lists and the projects mentioned at both sites).

What I do not really understand is it how it is that for ODE users anyone using Newton is because is an idiot that do not understand how physics works.

Well, I never mentioned anything about that, nor have I seen anything in the ODE community along those lines. But then again, the user base is alot larger than those frequenting the mailing list! Personally, I think it's more a matter of taste and licensing restrictions. That's it really. As I mentioned before - I find them comparable in terms of performance.

I was an ODE user for a long time before I started experimenting with Tokamak and Newton. I could never figured out the proper values of CFM and ERP, and the way I see it is the same for many people.

Well, I originally had no idea either. To be honest, it is not completely clear to me now! However, by describing the problems I was having on the mailing list, I was able to get results quite quickly from them with some advice on how to heuristically determine the values I need from the problem I was trying to solve. What's nice about my experience is that I was able to pickup info from users solving my exact problems (not to mention it's pretty cool to talk one the same level as the developers of BloodRayne!)

By the same token I fail to see how not having these features make ODE a "Simulation engine" and Newton a "Game engine" the implication being that ODE is for more advance people.

Where are you getting these "implications"? I agree that ODE is more capable of handling the advanced applications than Newton, but that has nothing to do with the people using it. For example, I have some matrix functions I use in conjunction with Irrlicht. They work well for what they are designed and optimised to do. That said, I have a different matrix library that I use for things such as fluid simulation & jacobian-based inverse kinematic solutions (the company I work for has several industrial clients).

I do not think that the cone collision is as simple as you try to imply, if it was then cylinders that are even simpler would be working in ODE, they aren't.

Well the dCylinder contribution seems to work well for most people, but even if that were not good enough for you - there is the "2D" solution described here (http://q12.org/pipermail/ode/2005-November/017258.html) I find it works for me

It is also worth noticing that it is not only cones, Newton also has other collision primitives. Maybe for you having optimized mesh collision, convex hulls, many collision primitives, closest distance calculation, collision scale, etc. are trivialities that do not contribute anything to a physics engine, I just find them a nice feature to have.

OK, now you're just being narky. I never said they were not useful, in fact I didn't say anything about them. But I will answer each feature with what I think about them:
Optimized mesh collision: Funnily enough, I really have no need for this. In general, I find that the speed to quality ratio is just not worth it honestly. That being said, ODE does provide the ability for tri-meshes to collide with other tri-meshes. *shrug*
Convex hulls: Quite right, I do not think a physics engine needs this. A geometry engine might, but I do not find it necessary that the physics engine calculate them for me. I want my physics engine to do one thing and do it well - that is simulate a physical environment. There is plenty of source code out for this particular feature when I need it. Type "quick hull" into Google and take your pick.
Many collision primitives: You are again quite right. I only want the collision primitives that I use. And I'm afraid I have (at this moment in time) no use for the cone or chamfer cylinder (the only two primitives offered by Newton not implemented in ODE).
Collision scale: This is trivially implemented by scaling inputs to & outputs from the simulation. This is not something that would make one engine more useful than another in my eyes.

I remember when the Newton came out, it was dismissed because it did not have enough features, now it is dismissed because it has too many features. Perhaps you are above the average game developer and you can tweak the “underpinning mathematiocs” of ODE, if so more power to you.

I have not dismissed Newton at all. I have simply stated that I prefer ODE due to it's licensing because I find the two on par in all other aspects. I do not see why that has caused such an outrage to be honest...

The bottom line is that trivializing the features and saying that you can add them to ODE in a couple of days does not make it a fact, and until that happens your claim that there is not much difference between them is simple not truth.

And this is another narky attack. I have not "trivialised" Newton in any fashion. I have backed up my statements (hence the length of my post), and more to the point - I do not see why I should implement something I have no need of (cones in ODE) because someone has found my preference for ODE "insulting" in some manner. Simply because I choose not to code these things for you does not prove that they are impossible or that I am incapable of them. As a wise man once said "Absence of proof is not proof of absence".

--EK

[Baal Cadar]

Some thoughts to add: ODE does not target for correction in their solution, but for stability and speed. The speed seems to be about the same and largely depends on the solver/stepper and the scene complexity.

But as for stability I found Newton to be more stable. Just one example, not a proof(no params are given, but as monster is a long-time ODE user, I guess he got it right), is the box stacking problem: http://www.ogre3d.org/phpBB2/viewtopic. ... 8868#58868

Granted, ODE has improved much in that regard in 0.5 over 0.039, as it doesn't explode anymore, but still Newton is more stable.

(Gotta go now, but more to come on this topic later today )

[Baal Cadar]

In an earlier post in this thread, I already explained that, having worked with both engines, I prefer Newton for the application my team and I am developing. I am a physics noob, I visited a physics 101 class in university and got decent grades in school, that's about it.

I want to delve a bit more on this, maybe helping others to make a decision about their project.

We develop an RPG game, not with Irrlicht, but with another popular 3d engine. So physics is not really an important part, we can spend much time on. What we need is:
* Decent collision between objects and the world and objects<->objects, for camera collision, player collision.
* Environment info that can be used for AI (NPCs shouldn't run into other NPCs when going from A to B)
* Basic physics to make the world more believable (pushing objects, rock slides, etc..)

And as a "meta-need", that applies for all of the above we want easy integration of the engine with the 3d engine and the game's framework.

The first aspect, the collision, is something both can handle properly. Certainly good enough for our project. So the ease of use comes in here, and in this part I found Newton to be superior.
Newton has a material system. You can define material like stone, wood, glass, concrete, etc. and setup collision parameters for pairs of such materials. And you can set callbacks for pairs, that could for instance start a sparkle effect, when the metal sword hits the stone wall and you can play a fitting sound. Of course, on top of ODE you can write this yourself too, but in Newtin it is already there. The characters and other creatures use up-vector-joints to keep them upright, again, one can implement such in ODE, but in Newton it is already there.

For the basic physics, it is again easily possible in both ODE and Newton, but Newton has the nicer interface here too. In ODE you have to poll all the objects to update the graphical representation. In Newton there is a callback called, if the position changes. As Newton is generally callback driven. I found this pleasant.
Also pleasant, but not yet needed for us, is the continuous collision mode. This is one feature I doubt, that it is easily integrated into ODE.

We don't yet have AI using the newton data to walk around objects, but Newton provides an API for this. No experience here so far.

On another note: Is ODE still in active development? There were only very few, mostly trivial changes in the ODE CVS in the last year.

And I seriously doubt that it needs only "half a day" to implement a cone primitive in ODE, needed or not. See here the implementation of dCylinder: http://cvs.sourceforge.net/viewcvs.py/o ... &view=auto
Maybe there are people who write this in half a day, I for sure can't.
This also shows another problem (not sure on this, so prove me wrong here) but from looking at the code, in order to add another primitive, you have to have special collision function for all the other primitives already there. Making the addition of yet another primitive more difficult than the one before.

[bernd]

I sometimes skim through the ode mailing list and got the impression that people were asking for more and better collision primitives for years. I really wonder why they aren't already there.

[Tim]

I was an ODE user for a long time before I started experimenting with Tokamak and Newton. I could never figured out the proper values of CFM and ERP, and the way I see it is the same for many people.

Well, I originally had no idea either. To be honest, it is not completely clear to me now! However, by describing the problems I was having on the mailing list, I was able to get results quite quickly from them with some advice on how to heuristically determine the values I need from the problem I was trying to solve. What's nice about my experience is that I was able to pickup info from users solving my exact problems (not to mention it's pretty cool to talk one the same level as the developers of BloodRayne!)

In other word the source code did not really helped you on anything, you are just riding along for the ride as many other people do. You are really impresses because others use ODE and you just follow the trend, but you do not know what they are doing, what ever it is being listed in the same list as “BloodRayne” people is some kind of a badge or honor to you.
Notice how you say that you do not know what those values are (neither do I btw) however you carefully call that heuristic.
Newton does any that it is says it has an exact solver (it seems that way as my experiment shown) but you have not problem calling what they are doing “well documented tricks”
I wonder why ODE does not do the same.

Optimized mesh collision: Funnily enough, I really have no need for this. In general, I find that the speed to quality ratio is just not worth it honestly. That being said, ODE does provide the ability for tri-meshes to collide with other tri-meshes. *shrug*

Here is something that I found fascinating, you seem to have the opinion that having an optimized mesh collision for clean contact is unnecessary and worthless, but the ability of tri-meshes to tri-meshes collision a must have. What you do not mention is that, that is just a feature list in ODE that does not work.

Optimized mesh collision
Convex hulls: Quite right, I do not think a physics engine needs this. A geometry engine might, but I do not find it necessary that the physics engine calculate them for me. I want my physics engine to do one thing and do it well - that is simulate a physical environment. There is plenty of source code out for this particular feature when I need it. Type "quick hull" into Google and take your pick.
Many collision primitives: You are again quite right. I only want the collision primitives that I use. And I'm afraid I have (at this moment in time) no use for the cone or chamfer cylinder (the only two primitives offered by Newton not implemented in ODE).
Collision scale: This is trivially implemented by scaling inputs to & outputs from the simulation. This is not something that would make one engine more useful than another in my eyes.

Do not forget ellipsis, and on the scale can scale can be done in Newton on real-time, also for example a cylinder can be squashed to make an elliptic cylinder, maybe for you that’s a trivial thing to do it is certainly not for me.

And this is another narky attack. I have not "trivialised" Newton in any fashion. I have backed up my statements (hence the length of my post), and more to the point - I do not see why I should implement something I have no need of (cones in ODE) because someone has found my preference for ODE "insulting" in some manner. Simply because I choose not to code these things for you does not prove that they are impossible or that I am incapable of them. As a wise man once said "Absence of proof is not proof of absence". --EK

These differences between what you say and what I say.
I am listing the things I found in Newton that makes me choose over ODE. What I listed is all facts. Newton has more feature than ODE and it is more stable, and when it come to real projects situation it is also faster. Those are facts.

You on the other hand disagree and debated every person that have some to say about the ODE vs Newton comparison. The only real fact you mention about ODE is the open licenses. Even thought you did say directly Newton is a trivial engine you have done worst than that.

You said ODE is better because it has a better name (really stunted me)
You said ODE is similar or more capable than Newton in performance (how, proof?)
ODE is a simulation engine and Newton is a Game engine (how?)
Collision features are trivialities beneath ODE capacity (I really apreciated them).
You also say ODE is better because it has more projects (you did not say it has been around for much longer).
You said ODE is more stable than Newton (that is not what the image shown in teh previus post showed)
You said that ODE is better because in the “ODE contains games, physics simulators, and character animation research. Last time I read the Newton forums the only projects & uses being discussed were games”

You had said every thing in Newton is based on tricks that can done in a couple of day in ODE while ODE is a heuristtic of “tweak the underpinning mathematics” (what ever that means).

Here is one that is totally incomprehensible to me. You say “A recent example of the benefits in being able to alter the underlying code is where a user altered an existing "joint" to allow for better simulation of a character on a tri-mesh terrain...” But later when I said you could extend Newton without having the need to modify the source code, you answered with this: “While Newton allows me to create new joint types - ODE allows me to tweak the underpinning mathematics. While I don't think doing so is a good idea for the average game developer - the ability to do so offers more flexibility than Newton can. The example of being able to write your own joint types has already been shown to be possible with ODE (in my last post no less *laugh*)”

In other word for you a feature only count if it can be done with ODE (BTW this is not an ODE feature you actually have to break the code to do that). Even more stunning is that the same feature that made ODE great, flexible and a simulation engine, mades Newton trivial, trickery and a game engine.

You know when you put all your reason together they do not look very objective and rational to anybody, The only thing concrete is that you like ODE because it is open source everything else are just subjective ideas you had created to convinced yourself that ODE is better.

[cassini]

Convex hulls: Quite right, I do not think a physics engine needs this. A geometry engine might, but I do not find it necessary that the physics engine calculate them for me. I want my physics engine to do one thing and do it well - that is simulate a physical environment.

The point is that physical simulation is exactly what ODE does not do better than Newton or any other of the free engines for that matter.
For that it needs to be stable meaning no exploding and no jitter. That has nothing to do with open source license, larger user base, or the presentation.

[Eternl Knight]

I'm not even going to bother going through all your points Tim, as it is obvious you prefer Newton and will read all my remarks through that perspective. As such, you are reading things into what I say that are obviously not there.

For example:

You said ODE is better because it has a better name (really stunted me)

Um, no. I used the name to show that Newton was created first & foremost as a library for games. I just reread my post on that to make sure, and I am still unsure how the hell you can get "the name makes ODE better than Newton" from what I wrote.

ODE is a simulation engine and Newton is a Game engine (how?)

Read their sites. Read the names of the engines. Look at the users. All of which I've pointed out before.

Collision features are trivialities beneath ODE capacity (I really apreciated them).

I not once said collision is a triviality. I said I had no use for the two extra primitives offered by Newton (cones & chamfered cylinders). Again with readinig things that are not there.

I was trying to have a civilised discussion on the whole thing, but it would appear that is impossible here. At least I read (and answered) what was actually said.

--EK

[Baal Cadar]

So, after personal wars are over now, I want this thread to actually help to be a guide for what engine to choose. Therefore I'd like to collect undisputed facts that constitute pros or cons for one or the other engine. (I have to leave tokamak out of the equation here, no personal experience, same goes for true axis and novodex)

* ODE is open source, and thus it can be extended by people who understand enough about phyiscs in general and ODE specifically to their specific needs.

* Newton is free but closed source, so only the API it provides can be used.

* Newton has more primitives, among them a convex hull primitive. (I highlight this one, because of its flexibility, as it allows for any other convex primitive to be simulated)

* ODE has collision spaces, which allow for handling collisions more efficiently, which Newton has no equivalents for.

* Newton is callback driven, while ODE must be polled, apart from collisions.

* Newton has a universal joint interface, which allows all kinds of joints, while ODE is open source and thus allows for joints to be implemented as an integrated extension.

* Newton has a material subsystem, which ODE has no equivalent for.

* Newton has a continuous collision mode, which ODE has no equivalent for.

* Newton has query functions on shortest path between two objects, which ODE has no equivalent for.

Any objections? Am I missing features?

I am not trying to value any of these traits, but just to list them. The value of each is determined by the specific projects to be implemented.

[cassini]

I used the name to show that Newton was created first & foremost as a library for games. I just reread my post on that to make sure, and I am still unsure how the hell you can get "the name makes ODE better than Newton" from what I wrote.
Read their sites. Read the names of the engines. Look at the users. All of which I've pointed out before.

Not to be anal but when you say that one engine is a simulation and the other is for game, you are implying that the physics of ODE are so much better than the physics of Newton that ODE is in a better category.
When you say read their site and looks at the users, you are actually saying that some how the user base in just a user base that just do games.
You know I had not found where does it say in the Newton site that it was created first and foremost as a library for games. I did find in many places that it was created for accuracy and stability.

I did a quick google search to find the places you’d mention saying ODE is a “simulation engine” while Newton is a “game engine” and I could not find anything.
I did however found some places saying just the opposite. Here is a sample.

http://robotics.ee.uwa.edu.au/papers/2004-AUV-Mako.pdf

Apparently these people found Newton “simulation enough for a real prototype.
Here is a quote for the PDF, there are more similar sites too.

“The user can select the physics libraries used by the
simulator. However the default physics simulation system
employed is the Newton Game Dynamics engine [10],
which implements a fast and stable deterministic solver.”

It looks like the evidence does not support your statements either.

I not once said collision is a triviality. I said I had no use for the two extra primitives offered by Newton (cones & chamfered cylinders). Again with readinig things that are not there.--EK

Well you make it looks like it is only a simplistic chamfer cylinder, and a cone. To be honest it is a little more than that, if you add the ellipses, arbitrary convex hulls, the ability to apply an arbitrary modifier to a collision to make skew and elliptical shapes, ray casting on all primitives, distance calculation between primitives, continues collision, correct inertia and volume calculation, buoyancy, optimized collision mesh, user defined static meshes, the list goes on and on.
It does look like you are not telling the complete story; it would be really nice if you rebut those features with counter features in ODE. But what you are actually saying is that ODE is a better engine because it does not have any of those features.
I am sorry but that is how it coming across.

[Eternl Knight]

As Baal Cadar put it - I am not going to pursue "personal wars". To date, he has been the only one not reading things into what I said that are not there. I like what he is trying to do, but do not see it being possible for me to continue without the whole "war" thing continuing.

As such, I am not going to post any further. I will continue to read it, but I am not a zealot and cannot be bothered defending the choice of physics engine that others might make...

For Baal Cadar:

• ODE can simulate convex polytopes as well, it's just you have to create them yourself (as a tri-mesh).
• ODE can be compiled to run on almost all platforms with a C++ compiler (i.e Solaris, FreeBSD, etc) whereas Newton is limited to the MacOSX, Linux. & Win32 platforms (it might later be released on other platforms though).

I think those should be relatively safe - anything else I might add seems to spark controversy.

--EK[/list]

[Leader]

i prefer Newton because its very easy in use and easy to integrate with Irrlicht. I like newton's callbacks

[raimian]

where can i get a copy of irrlicht with ode intergrated into it??

im new to programming and im wanting to use irrlicht and ode but im not sure how to intergrate the two together.

any help will be greatly appreiceated

[Eternl Knight]

Actually there is a tutorial for integrating ODE into Irrlicht on the main Irrlicht site, along with tutorials for integrating Newton & Tokamak.

There is also an "engine" of sorts available called "MyWorld". Have a quick search through the "Project Announcement" forum, it'll be somewhere near the top (I think there was an update recently).

--EK

[xhrit]

The NASA computational sciences division is using ODE in it's "Mission Simulation Dynamics Engine".

http://ic.arc.nasa.gov/msf/project/efforts.html