NewtonBodyGetOmega inaccurate

[MiCroN]

Hi,

I have a problem with the accuracy of newton's integration. I tried the following with Newton 1.53 in the first tutorial (getting started). I disabled the angular and linear damping, set an angular velocity of (0.0, 10.0, 0.0) when the body is created, and output the result of NewtonBodyGetOmega after each NewtonUpdate. I also set the sphere radius to 1.0 (in all directions) and the mass matrix to Ixx = 1.0, Iyy = 1.0, Izz = 1.0.

The result of the angular velocity seems to increase after each update. It's almost as if there is an inaccuracy in the calculations in Newton that keep adding up. I know it can't be accurate all the time, but this just seems weird to me. That is if this is the cause, maybe there are other settings I can try..

Shouldn't the angular velocity not change at all, it's a setter and there are no forces working on the object? I have not tried this with linear velocity yet though.

[agi_shi]

PM Julio Jerez on here for a link to the 2.0 betas (currently at beta19). Practically no one uses 1.53 anymore. 2.0 is a lot faster, more stable, and feature-complete.

[MiCroN]

Ok, but it is still in beta right.

That's kindof the reason I didn't want to use it yet, but I'll try it, thanks

[agi_shi]

Yes, still in beta, but a lot more stable (and useful) than 1.53.

[Julio Jerez]

Ok, but it is still in beta right.
That's kindof the reason I didn't want to use it yet, but I'll try it, thanks

Yes I can not force you to use it.
The Beta is public now and it does not requires instalation and do not put anywher outside teh root fordel of the SDK.
Yon can just download into a temp fordel, run the demos and if you do not like it, just drag it to the recicle bin, it will go away.

[sea]

I recommend you Newton 2.0 beta because it's more powerful than 1.53. There is some lack of 2.0 wiki though.

[MiCroN]

Well, when I started using Newton the Beta was also in the picture. It's just that I work for a company (Kalydo) and it didn't seem like a good idea to start using a beta version. Now I think I'm running into the limitations of Newton 1.53, and next to ODE I'd like to have another physics library implementation in our engine.

I've heard some good things about Newton 2.0, and I hope most of the limitations in 1.53 are not an issue anymore. But it's probably like I always say here, there is no holy grail, nothing is exactly the way you would want it to be (unless you build it yourself), so it's probably a very good idea to have more than one implementation. But I'll stop ranting, before I start a whole discussion we might not want to have .

Anyway I'll try the beta! Btw, does that mean there is no 2.0 wiki?

[Julio Jerez]

I've heard some good things about Newton 2.0, and I hope most of the limitations in 1.53 are not an issue anymore.

I am always looking for feedback from users that are actually interested in using the engine.
many time people see stuff that is not right and assume is the way it is.
Sometime the problem is bad modeling, other time are bugs, and some other actual shortcomings.
Believe or not there is a lot of apathy form casual use and engien haters, and most the time all I get is the opinion of the appraisal that go by features they see on other libraries.
and even if the feature is perfectly supported they prefer to ingnored it.

If you list some of the problems you had with 1.53 I can tell you if it had being fix or improve.

[MiCroN]

Ok, I'll try :p

- Reference counted collisions can't be used properly. When you need to create an X by X box (no pun intended), where X can be any value, you can't really take advantage of the reference counting.
- materials groups are anoying when you have to set the collision between each group separately, hence I use the default material and override it's settings.
- the name collision seems odd :p
- the NewtonBodyGetOmega thing I mentioned here
- no support for angular/linear motors like in ODE
- less performance than ODE (but I haven't measured/profiled anything, just a scene in our engine with a lot of falling stacked boxes)
- Convex dynamic mesh, i'd also like a concave one :p
- SetWorldSize, can't the world be sized automatically? (I know Havok has that as well, and I wonder about the same thing there)
- documentation sometimes has strange comments
- e.g. NewtonMaterialSetContactKineticFrictionCoef, had some kind of comment that the order of setting kinetic/static friction was important, but i can't find it on the wiki now. Well, documentation is always an issue isn't it
- at first glance it's not clear how to make a static body. But that could just be me being set off track by ODE.
- scaling can't be put in the matrix. That's ok, but if it's documented it'd be better.

Well that's all from the top of my head. Maybe I had more once, just can't think of it right now.
This is mainly compared to ODE though, and I must say that I have never build a physics library (I'd like to but can't really find the time :d). I have fiddled a bit with PhysX and Havok, but for one i don't think it's fair to compare to them and also I haven't tried the things I'm trying now.

So that said, I love the use of callbacks, but I think you need to be carefull what you design as a callback. Though I don't really have an example of a bad callback, the applyForceAndTorque callback is a very good idea I think! Also, it says in the documentation of some functions that they are capped to a certain value. I guess that's ok, but to me just another thing to be carefull with. You might limit a user too much, which is not necessary. Like NewtonMaterialSetContactKineticFrictionCoef or NewtonSetMinimumFrameRate (which seems like a strang function btw, Newton doesn't perform sub-stepping or does it? If it does that one is also not clear in the documentation). I understand there are some design decisions that were made so the user can easily integrate Newton, I'm just saying that in my view it sometimes has the opposite effect. So I like the flexibility ODE offers with it's lower level nature, and the ease of use that Newton offers with its callbacks and body to proxy mapping. But trust me, I got issues with ODE as well.

I bet many things I said are not clear, I'd be happy to elaborate .
Haven't tried the beta much yet, but I'm looking forward to it! Just dunno when I'll have the time.

[Julio Jerez]

- Reference counted collisions can't be used properly. When you need to create an X by X box (no pun intended), where X can be any value, you can't really take advantage of the reference counting.

You do not have to ref count you bodies,
You can call make unique righ after creation the body, and that will relinquish the ref count.
I suggest you do use ref count for efficiency.

- materials groups are anoying when you have to set the collision between each group separately, hence
I use the default material and override it's settings.

Yes for litle knowledge of the Law of physics they are confusing, but that is how the laws of phsyics works.
Neverthenless you can use the method you want, you are telling me that because the material graphs is there in made less usefull?

- the name collision seems odd :p

How would you name them?

- the NewtonBodyGetOmega thing I mentioned here

And what that is?

- no support for angular/linear motors like in ODE

This is no truth, Newton have a generic interface for making any king of find you want, the include all kind of the so call linear and angular motors.

- less performance than ODE (but I haven't measured/profiled anything, just a scene in our engine with a lot of falling stacked boxes)

I believe that at the level of accuracy and stability of Newton, Newton is by fast the faster physics engine around, that include Physx and Havok, and all of the open source spin off commercial libraries by ex employees.
I am willing to put my money where my mouse is on this want.

- Convex dynamic mesh, i'd also like a concave one :p

No concave mesh at this time

- SetWorldSize, can't the world be sized automatically? (I know Havok has that as well, and I wonder about the same thing there)

Why?

- documentation sometimes has strange comments

??

- e.g. NewtonMaterialSetContactKineticFrictionCoef, had some kind of comment that the order of
setting kinetic/static friction was important, but i can't find it on the wiki now. Well, documentation is always an issue isn't it

if you new the basic law of Netonian physic the will be perfectly clear to you.
It means you cannot set the static coeficient of friction that in lower than the kenetic friction.
I did not invented that Law Coulomb did.

- at first glance it's not clear how to make a static body. But that could just be me being set off track by ODE.
NewtonBodySetMass (body, 0, 0, 0, 0);

I do not think it can be easier than that, but how knows.

- scaling can't be put in the matrix. That's ok, but if it's documented it'd be better.

Dynamics object can be scaled by using a shape scale modifier.

I did not want this to be a referendum on Newton vs ODE, nor do I want you rcondescendency about Netwon is an alternative to ODE because is easier to integrate.
You are the want making teh comparing an dpaintion teh Face of ODE into newton, and I will tell you Newton is not ODE.
Newton is what it is because it is how I made it.
If you think it is inferior and you and to map ODE into newton I suggest you continue using ODE and forget aboput newton SDK, plase let it go.

Good bye

[agi_shi]

I know Julio already answered, but I just want to add in my 2 cents:

- Reference counted collisions can't be used properly. When you need to create an X by X box (no pun intended), where X can be any value, you can't really take advantage of the reference counting.

Referenced counted collisions have worked for me since 1.53, not sure what you're talking about. If you want different boxes, use different collisions. The whole point of reference counting is to ease memory and speed for collision objects that are the same.

- materials groups are anoying when you have to set the collision between each group separately, hence I use the default material and override it's settings.

That's how physics work. I override the material myself, but for real control you really do need material groups.

- the name collision seems odd :p

Give us a better name.

- the NewtonBodyGetOmega thing I mentioned here

Check the 2.0 betas.

- no support for angular/linear motors like in ODE

What are you talking about? Newton has the most complex custom joints I've ever seen.

- less performance than ODE (but I haven't measured/profiled anything, just a scene in our engine with a lot of falling stacked boxes)

Test 2.0, and make some scene more complex than just a couple of boxes. Newton's performance is beastly when it comes to joints and complex physics.

- Convex dynamic mesh, i'd also like a concave one :p

NewtonCreateCompoundCollision(), I have loads of concave dynamic objects in my project.

- SetWorldSize, can't the world be sized automatically? (I know Havok has that as well, and I wonder about the same thing there)

What for?

- at first glance it's not clear how to make a static body. But that could just be me being set off track by ODE.

Set the mass to 0. Can it be any easier?

- scaling can't be put in the matrix. That's ok, but if it's documented it'd be better.

It can be put in the collision modifier matrix.

[MiCroN]

I appologize, I got a little carried away there and should not be turning this into a referendum on Newton vs ODE. That's not what you asked for, but you did ask me for feedback and problems I ran into. So that's what I tried to give from a programmers perspective. It is off course entirely possible that I misunderstood the use of some functions and I thank you for pointing them out to me.

- About the reference counted collisions, materials and motors, true, they can be used properly. I was too fast with that.
- I would name a collision, a geometry or a proxy I think.
- I know compound bodies can be concave and that rules.
- SetWorldSize, why not have it set automatically AND have the option to set it yourself? Why do I have to worry about the size of the physics world? It's just an idea, maybe it is a dumb idea, it probably has a very good reason. I'm just being a dumbass user here.
- static objects, true, it is easy. When I first started using Newton however I had no idea, couldn't find it in the documentation and some forum topics mentioned otherwise. Yes the samples show it very well, I'm just saying.
- NewtonMaterialSetContactKineticFrictionCoef, another fault of mine. I do know Newtonian physics, I get why you enforce the order now, and it's probably a good idea on hindsight.

Again I appologize that for being too fast with some points I was trying to make, I was just trying to give feedback. Now a few questions about 2.0. Is there a wiki for 2.0 specifically? And is there support for kinematic objects?

thank you

[Julio Jerez]

So of the things you listed the only real issue feature is the generic concave mesh.

The performance, I believe you are testing version 1.53 with have a linear to quadratic solver.
I am going to refer you to at least test 2.0,
The solver ha linear time complexity with mean is about one order of magnetos faster for large scenes.
It is no better in all count that the exact solve because the inner loops have lot more steps, than the general solver.
The general solver had also being made faster in 2.0 and more stable.

For the general concave mesh, I am still working on that. The problem with general concave mesh is not just how to find the face a shape is colliding with, the biggest problem is to determine the quality of the contact generation.

The reason this is and unsolvable problem is because it is a unfishable mathematically,
Mathematically the definition of a contact in the point and the surface normal and the point at the instant tow body touch each other.
The thing is that for a concave edge they will never happen.
This sound like and easy Lemma, but it is much more complex than you think. This is because even those you know that concave edge do not generate contact the fact that the physics is evaluated at discreet step will make an intersection algorithm to find edge contacts. When it does happen you need to provide a solution. No heuristic will find a solution because this is a non exiting problem therefore with does not know how an body should react when it hit a concave edge because it is and even that never happens.

Given that fact how do you solve the issues, the solution is to do back tracking and find the real point at which the body intersect for the first time and collide the tow face normal’s at that point.

Her is the difficulty when you gave two generic shapes this became a parametric N body problem, an not CPU can deal with that efficiently.
The only way to deal with that I know is by using brute force with a large number of processors.

I have seen how in the world of eth self appointed experts the run around claiming the functionality, just because they can do a geometric integration on two polygonal soups.
Then you can see how these features gradually fade away and are discourage to the user.

These people are a group of intellectually dishonest individual’s the use this kind of deception to attract casual user with the purpose to spread propaganda.

This is how you see these competing open source collision physics and collision with a large set of features that do not really work, but that make a lot of noise amount the casual users.
I will never do that.

However I am looking at the new GPU like ATI and Nvidia CUDA, and believe me all those features that require brute force CPU power like cloth, soft bodies, destruction, generic concave collision will be implemented. Make no mistake about that.

[agi_shi]

And is there support for kinematic objects?

You mean objects that can be manually moved but cannot be pushed around by other objects? See here: http://www.newtondynamics.com/wiki/inde ... TriMesh%3F

[MiCroN]

No that is not the only issue I had with version 1.53.
It is indeed the least of my worries. Convex meshes are very stable, maybe even more stable than ODE (sorry for the comparison), no doubt because of the reasons you describe. The only (real) issue I had with 1.53, was what I was trying to describe when I started this topic, with setting/getting the angular velocity of a body. I will look into it with 2.0.

Most of the other things I mentioned are not an issue of newton, but just an issue of mine. And I believe, that is because of how I use newton and how it is integrated in my own stuff. So, again I was too fast by mentioning them, and I will not mention my own problems again (unless there is interrest, and time).

ow and thank you agi_shi, I was doing something similar with another integrator. I'll try this one as well.