As it turned out, the emperors had not cloth.

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

As it turned out, the emperors had not cloth.

Postby Julio Jerez » Mon Jun 15, 2015 1:11 pm

For years we have read comment that Bullet and Physx are better than Newton.
These comment are all based on false evidence by people like Adrian Boeing, Dirk Gregorius or by Fan boys that do not really know what they are talking about, but they gives opinions anyway.
well now there is a way in which these engines can be compared side by side doing the same thing.

http://www.newtondynamics.com/downloads/PEEL-master.rar
http://www.newtondynamics.com/downloads/PEEL-master-1.1.rar

these integrations are made by the respective developers as opposed to what the dishonest
Adrian Boeing and Dirk Gregorius did in PAL where they make Bullet look good by making every one else, in particular Newton, look bad.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Tue Jun 16, 2015 8:11 am

Hello everybody,

So that's my first post here. Got a link to the forum from: https://github.com/Pierre-Terdiman/PEEL/issues/3

I don't really have the time or motivation to argue about old posts from other people on other forums. If you're interested we can discuss your Newton integration to PEEL here. I don't mind working with you on that, and/or adding a better integration to the next version of PEEL. Or you can use your own version of PEEL here, as you just did - fine with me.

I will have a look at your modifications ASAP.

One thing I noticed though is that the PhysX 3.3 integration seems to be broken in your version: in the "SphereMeshUnitTest" scene the sphere starts moving and eventually leaves the mesh. This does not happen with the PhysX 3.3 trunk from the public PEEL releases (http://www.codercorner.com/blog/?p=1176). So maybe let's start with that. Could you have a look?

- Pierre
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Tue Jun 16, 2015 10:02 am

Oh well thanks for commenting.
Well I do not know much about that particular test. I do not even understand what it means, seems to be a very small ball resting of a congregation of a bunch triangles.
With Newton when people want to do something like that, (a golf game come to mind)
I simple tell them to use Continue collision.

In any case with exception of adding virtual interface functions to your physx 3.3 and bullet wrapper, I did not touch it, that is what I got about a year ago from one of your under an NDA.
I forget about until last week when someone brought the attention to me.
That is the reason BTW that I could not add all the other compiled libraries so it may be that those compiled libraries are fine while the one you gave me has a bug.

One thing I do notice is that In all the test you claim are stress test that are supposed to be Difficult for other collision libraries, it is Newton the only library that passes the test while Physx 3.3 and all the others fail. So by your own criteria, it is Newton that had the upper hand on those test.

In any case, I will remove this download link and put a link to your GiIthub site as soon as you integrate Newton the Proper way.

What I am not going to let happen is what Mr. Adrian Boeing, Mr. Dirk Gregorius and Mr Kenneth Bodin and his students did 9 years ago with the Garbage they published and that Mr. Erwin Coummans uses like a weapon to undermine Newton knowing well that was and still is a pile of Garbage. Meanwhile me and some of my users could only seat and watch how the conspiracy unveiled not being able to retaliate because Adrian Boeing was protected by a license. This time around I will replay.

So I will do better that what you ask, I will remove the link as ass son as you integrate Newton the way it is supposed to be done.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Tue Jun 16, 2015 3:56 pm

I do not even understand what it means, seems to be a very small ball resting of a congregation of a bunch triangles.


The test does not 'mean' anything special. As its name suggests, it is just a unit test (regression test) for an issue we had a while ago. At some point we had a bug in the code and the sphere was jittering in that particular corner of the mesh. Each time we fix a bug we create a repro test to capture the problem and make sure it does not appear again in a new version. That one got ported to PEEL to see if other engines had the same issue or if it was just a plain bug in our code (it was).


that is what I got about a year ago from one of your under an NDA.


Oh. You mean these are not the PhysX 3.3 DLLs from the PEEL release? If these are the ones you got a year or so ago, then I suspect this test was just broken in our trunk at that time. Ignore my question then.

But we need to change this. If you want to look at performance comparisons, using our old trunk from a year ago is a bit pointless. Who knows in what state it was at that time?

More importantly perhaps, I think you are not allowed to release these NDA-covered DLLs - even if they are obsolete now. I personally don't think it's a big deal but I am not a lawyer.


That is the reason BTW that I could not add all the other compiled libraries


If you changed the interface the precompiled libs (the "PINT" plug-ins) won't work, but I think you can still recompile these plug-ins to use your modified PEEL with the more recent PhysX 3.3/3.4 DLLs. Anyway, no big deal.

so it may be that those compiled libraries are fine while the one you gave me has a bug.


Yes, exactly.


One thing I do notice is that In all the test you claim are stress test that are supposed to be Difficult for other collision libraries, it is Newton the only library that passes the test while Physx 3.3 and all the others fail.


I am not sure what you mean. There are performance tests grouped in a "performance" category. Different engines will take different a amount of time to simulate the scenes. But there's no "passing the test" or "failing the test" in these ones. They all pass the test, some more quickly than others.

There are other tests where you could say that some engines pass the test and other fail, but they are usually not performance-related (for example contact generation tests).


So by your own criteria, it is Newton that had the upper hand on those test.


Tell me which tests you have in mind, and I can have a look. In my PEEL Release Newton was especially good for joints IIRC, but not particularly for performance. I may not have used the latest version though.

In any case, I will remove this download link and put a link to your GiIthub site as soon as you integrate Newton the Proper way.


So I just had a brief first look, but I am a bit confused already. You have two plug-ins:

PINT_Newton_3_9.dll
PINT_Newton_3_13.dll

I think the "3_9" version is actually using Newton 3.12 (correct me if I'm wrong). That one works.

Then the "3_13" version is probably using Newton 3.13 I guess, but it crashes for me at startup time. Looks like an "invalid instruction" exception due to "dpps". Right? My PC at home does not support SSE4, so I get a crash.

The confusing thing is that in my own PEEL Release I am using Newton 3.13 as well (or I thought I was), and there it works fine on my machine. So this 3.13 version does not seem to use SSE4. But it's the same version number. So I'm confused.

Any idea what's going on? Did you change the 3.13 code recently without changing the version number?

If you use SSE4, I won't be able to test your stuff. None of the other engines use it (not even Havok), so I'm not sure the gains are worth the loss of compatibility with common PCs. But that's your call...

- Pierre
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Tue Jun 16, 2015 5:43 pm

what it was there at that time was Physx 3.31, it came with the archive there was not source code there, just the headers and libraries.
And yes the other dll would not run if I add a couple of interfaces function to the PINK base class. And not, I do not go around downloading source code from everywhere to test stuff I prefer compile code already, I do not even profile my own stuff. This is the very first time I actually compare a version of Newton to another version of Newton so I am grateful for that.
Newton 3.13 may very well be slower than 3.12 but if that is what it takes to make it right, that is what it is.

>>I am not sure what you mean. There are performance tests grouped in a "performance" category…<<
I mean the test where you place comments saying “this is a triangle edge collision the ball should state in place and no role alone the edge, very few engine can do it”, or the one where you "stack 50 boxes pyramid and declare victory because one one can do it and you say only my private engine can do this", , and so on and so forth.

As for the 3.09, 3.12, 3.13
3.09 does not longer exits, I do not keep copies of the engine it is all in source control and since Google do not allow stable releases any more the only way to get it is by going back in SVN, so I just took the last stable version 3.12 and copied on the 3.09 folder. You can rename it you want.

About 3.13 you took a work in progress, not a stable release. Since I now do have the stable 3.13 in github that is the version that I used. Not the work in progress.

For the SSE4.1 code, people hwo use newton do local customizations by changing some defined.
Some people disable multi threaded, by uncomment
Code: Select all
//#define DG_USE_THREAD_EMULATION

Some people disable the SSI4 code by commnting
Code: Select all
#if (defined (_WIN_32_VER) || defined (_WIN_64_VER))
   #define DG_SSE4_INSTRUCTIONS_SET
   #include <intrin.h>
#endif

And some people even run with plain single scalar x87 code by uncomment
Code: Select all
#define DG_SCALAR_VECTOR_CLASS

Newton use 1 mg stack size, but you have some test that cannot run on 1 me size so I have to compile
with
Code: Select all
#define DG_ENGINE_STACK_SIZE        (4 * 1024 * 1024)


with one Meg size which is the default in window it will handle all the scene except the one where to crate 255 x 255 static rigid bodies.
But I never saw any body make scene with that number of physic entities. In newton people will use a Scene structure and that is optimized for that and uses less than one tenth of the memory and have zero overhead CPU cost.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Wed Jun 17, 2015 5:09 am

what it was there at that time was Physx 3.31


Ok. Yeah, so PhysX 3.3.1 is "old" now. The "PhysX 3.3" dlls from the official PEEL release would be equivalent to "PhysX 3.3.4".


And yes the other dll would not run if I add a couple of interfaces function to the PINK base class. And not, I do not go around downloading source code from everywhere to test stuff I prefer compile code already


"PINK" :)

Well you don't have to recompile PhysX itself, but if you modified the PINT interface you must have recompiled the PhysX 3.3 PINT plugin, otherwise it would not work anymore. So all I'm saying is that you could probably make it work with the more recent PhysX DLLs if you wanted. But no worries, I can take care of it.

I do not even profile my own stuff. This is the very first time I actually compare a version of Newton to another version of Newton so I am grateful for that.


Err... You switched to SSE4 without profiling anything? :shock:

Newton 3.13 may very well be slower than 3.12


I'm at the office now and here both versions work (no crash). From just running a few scenes it looks like sometimes 3.12 is faster, and sometimes it's 3.13.


I mean the test where you place comments saying “this is a triangle edge collision the ball should state in place and no role alone the edge, very few engine can do it”


That would be "SphereMeshUnitTest_EC". Here's what I see for this one:

- the Newton 3.13 I used fails (probably because it was a work in progress, fair enough)
- your Newton 3.13 works
- Newton 3.12 fails
- PhysX 3.3 fails (we spotted the issue in that version so that's when the test was added)
- PhysX 3.4 works

The test is indeed "supposed to be difficult", it's not a stretch to write that. It did fail in many engines, including in your own until 3.12, so I think the description is fair.

What typically happens is that people discover a problem in their engine thanks to PEEL, and then they just go ahead and fix the problem in their next version (as you just did). It happened a few times already with different engines.

So anyway, good job making that one work. You are not the only one passing this particular test though...


or the one where you "stack 50 boxes pyramid and declare victory because one one can do it and you say only my private engine can do this"


With all due respect, you have a curious way to present things. You use a lot of terms like "victory" or "retaliate", like we're all in some kind of battle. We're not. I'm not, in any case. I'm interested in physics engines (all of them), and while I enjoy some friendly competition (because it usually results in everybody's code becoming faster/better), it's not much fun if you take it too seriously.

So, no, I did not "declare victory" and I never said "only my engine can do it" (WTF??). Havok can do it. Newton can do it. PhysX 3.4 can do it. I wrote something like "this test is just to show off with ICE Physics" because as far as I can tell it simulates that particular scene with the best overall performance/quality. That's all.


About 3.13 you took a work in progress, not a stable release. Since I now do have the stable 3.13 in github that is the version that I used. Not the work in progress.


So which version(s) would you like me to include in PEEL? Only 3.13? Or both 3.12 and 3.13?

For the SSE4.1 code, people hwo use newton do local customizations by changing some defined


Ok I'll try to recompile 3.13 without SSE4, just to be able to work on this at home.


Newton use 1 mg stack size, but you have some test that cannot run on 1 me size so I have to compile with...


I am not sure I follow this. 1Mb is the default stack size on Windows indeed. And we don't touch that. All the tests run fine with the default.

So if it does not work for you, it means there is an issue in Newton itself, like maybe a recursive function that should be rewritten in a non-recursive way.


But I never saw any body make scene with that number of physic entities.

We did.... more than once.... We got a lot of customers complaining about 64K objects limit in previous PhysX versions.

In newton people will use a Scene structure and that is optimized for that and uses less than one tenth of the memory and have zero overhead CPU cost.

Hmmm. Why don't you use a Scene then? We certainly do.
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Wed Jun 17, 2015 11:01 am

Pierre wrote:Ok. Yeah, so PhysX 3.3.1 is "old" now. The "PhysX 3.3" dlls from the official PEEL release would be equivalent to "PhysX 3.3.4".

Oh. I see does that means that at some point Phsyx 3.31and lower was good and then it was not good
after 3.4?
you were using the same exact arguments to demonstrate the Physx 3.1 was better that everyone else, and before that the same exact arguments to demonstrate that 2.8 was better the everyone else, and even before that the same exact argument to demonstrate that novodex was better than every one else. and that would fine fine if it was for protional of you own stuff.
But when you guys start to write the stuff on documents and the stuff start to percolate down to even the academia realm, I do have a problem.

There is a lot of dishonesty and naiveness in the part of the student Academia and there are some individual that capitalize on that in order to promote themselves and tier side companies. There is typical c of the Computer science department at Umea University.
case in point: http://www.bulletphysics.com/ftp/pub/te ... gRolin.pdf

when I know far well that Newton was so far superior that Novodex and Ode and even than Vortex.

Better that Novodex because it already has all kind of collisions shapes, all kind of joints and things did worked as expected, bud it did not scaled well to large number of objects because of the quadratic time complexity of the solver.

and better than ODE because ode piece of nonsense iterative solver did not work back then and still does not work today, and the Danzig direct solver is an O(4) best case and NP worse case time complexity while Newton line search has an O(2) average with and O(3) worse case complexity but this idiot did not even realize what they were doing.

These idiots decided to compares apples and oranges by comparing and iterative algorithm to do the one that was not and credit the results to the iterative algorithm to the altenate direct Danzig solver. That was dishonest.
Buy is was a lot more than just that, they concluded Newton solvers did not conserve angular velocity, when it was just the opposite.
It won conserve angular momentum if they do not set the Angular Drag to zero, it will blow up if they do not set Material Properties, it will blow up if the do not set joint stiffness. and so on a so forth.
Then I see Adrian Boeing and the rest of the engine appraisal doing the same over and over every year pretending they do not known better by just ignoring the people who correct them.
Then now 9 years later I see you repeating the same mistake and arriving to the same conclusions.

yes I called that dishonesty and I have a huge problem with it.

Err... You switched to SSE4 without profiling anything?

has it occur to you that when you are writing a class for the first time you use what is available, and when you review over time you add new features as they show up. what the that has to do with profiling?
did not I added a defined so that it can be configured.

I'm at the office now and here both versions work (no crash). From just running a few scenes it looks like sometimes 3.12 is faster, and sometimes it's 3.13.

one big difference between you and I is that I am not obsessed with being the fastest at all cost.

That would be "SphereMeshUnitTest_EC". Here's what I see for this one:

- the Newton 3.13 I used fails (probably because it was a work in progress, fair enough)
- your Newton 3.13 works
- Newton 3.12 fails
- PhysX 3.3 fails (we spotted the issue in that version so that's when the test was added)
- PhysX 3.4 works

The test is indeed "supposed to be difficult", it's not a stretch to write that. It did fail in many engines, including in your own until 3.12, so I think the description is fair.

What typically happens is that people discover a problem in their engine thanks to PEEL, and then they just go ahead and fix the problem in their next version (as you just did). It happened a few times already with different engines.

So anyway, good job making that one work. You are not the only one passing this particular test though...

No Newton 3.12 and any other versions all the way down till 2.00 do not fail that test, they work as they are designed to work.
In all version prior to 3.13 polygons are convex shape just like any other convex shape.
The way it works is that at construction time faces are welded, any face pair with a share convex edge are flagged as having a voronoi region. if the edge is flat or concave they are not flag it because there is not possibility that a convex shape can hit a concave shape and that is a demonstrable fact therefore they can only have one Voronoi feature, the face.

That however leaves one problem, loose faces that do not have share edge will also be flagged as having one face feature. so the collision system unaware the face is a polygon make seen as a convex shape, will come back with a face contact . so in Newton 3.12 and lower the ball will roll down the ramp because it get a face contact.

in Newton 3.13 I realized that if I add a fake convex skirt to all lose faces, It will save me some extra calculation in low lever collision routine because it does not have to do a post processing pass to determine if the feature was edge or face, and if it was edge, then and open edge, then it must rotate the normal to align to the face normal. That was for improvement not because of peel.

I would not do it if it did not translate to a more elegant and cleaner solution.
Because contrary to your assessment, given that flat faces with lose edges do not really occur in nature or in practice, then the solution choices are not between an edge and a face they are between a face and a nonexistent edge. :)

I am not sure I follow this. 1Mb is the default stack size on Windows indeed. And we don't touch that. All the tests run fine with the default.

So if it does not work for you, it means there is an issue in Newton itself, like maybe a recursive function that should be rewritten in a non-recursive way.

there you go again, you formulate your own questions to answer your won presupposed answerers.
There is nothing wrong with setting a thread stack size. that's which all thread libraries has the stack size as a parameter, Newton does not changes the stack size of the main thread either, furthermore the stack size is a configurable parameter.
It just happen that stack size leads to more elegant an cleaner algorithms, what makes you think that it most be because I am doing some recursive functions?

We did.... more than once.... We got a lot of customers complaining about 64K objects limit in previous PhysX versions.
In newton people will use a Scene structure and that is optimised for that and uses less than one tenth of the memory and have zero overhead CPU cost.

Hmmm. Why don't you use a Scene then? We certainly do.
[/quote][/quote]
again you formulate questions to answer your own presupposed answers. you think that because you call something a scene and I call something else the same thing that we must be talking the same about the same and we are not.
In Newton a collision Scene is simply a compound collision that can be seen as a single shape by the broad phase. the reason I did not used it is because your tool is because you tool do not provide interface for that, does it?
you created a bunch of bodies, no way to detect that is meant to be a special test.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Wed Jun 17, 2015 6:21 pm

I am not obsessed with being the fastest at all cost.

You are obsessed with Adrian Boeing. That's a LOT worse :twisted:
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Wed Jun 17, 2015 7:45 pm

you see that was funny. :mrgreen:
an yes I am. but who I am really obsessed with is with Mr Kenneth Bodin and his partners

You do not know but there is a story behind. When Newton first showed up in the scene as a strong competitor to ODE and sudtlently many companies in the simulation area started to switch from ODE to Newton and from Vortex to Newton.
His solution was to derail Newton by using his students, his "Battery of test" and his pseudo papers that he used like weapons to flood the internet with Garbage like this.
test.png
test.png (5.45 KiB) Viewed 13201 times

apparently Vortex can invert singular matrices, but he never published vortex on that study.

Adrian is just an ambulance chaser trying to make a buck.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Thu Jun 18, 2015 2:13 am

Ok Mr. Since you asked to be enlighten, I made a small movie to explain why PhysX or Bullet are not really a physics engine the are it is a kinematic engine that resolve interpenetration.
take a look at this movie

check out I can hit hard the Newton Pyramid and can even punch holes on it and it still wants to state up and after the collapses, still leaves the base up.

then check the Physx 3.4 pyramid first I hit it at the bottom once and the entire thing comes crumbling down like a controlled demolition. Then to make sure I did not cheat, the second time by gently pull one block out and again the entire pyramid comes crumbling down.
That is what I meant when I said that to declared victory first you have to solve the problem. what good does it make having a something like that when a feather can destabilize it?

These are the kind of things the Newton library offer to the users that even non expert can use I and the state with it. Almost 100% of the people who are still using Newton are ex users of PhysX, Bullet and ODE that come here out of desperation and frustrations.
and those are the kind of things that these morons like Being and Bodin do not address in their weaponized internet pseudo papers.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Thu Jun 18, 2015 8:58 am

Oh. I see does that means that at some point Phsyx 3.31and lower was good and then it was not good after 3.4?

Come oooooon. No, it means the new version is better than the old version.

you were using the same exact arguments to demonstrate the Physx 3.1 was better that everyone else, and before that the same exact arguments to demonstrate that 2.8 was better the everyone else, and even before that the same exact argument to demonstrate that novodex was better than every one else.

I have no idea why we suddenly go all the way back to Novodex :)

I suppose it makes a lot of sense that, at a given point in time, when comparing libaries A and B, one should use the latest version of A, and the latest version of B. It seems obvious, I'm sure you agree, so I really don't know why you seem to object.

Look, you came to GitHub complaining that I was not using the latest version of Newton (or the proper integration, I am still not entirely sure what you were complaining about). And yet here in this very thread, in your own branch of PEEL, you do exactly the same .... i.e. you use the latest Newton against a two-year old version of PhysX. Right?

So I'm just pointing this out, that's all. I propose we just ignore this now and continue - otherwise I'll never get started on the new integration.
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Thu Jun 18, 2015 9:24 am

http://www.bulletphysics.com/ftp/pub/te ... gRolin.pdf

I don't know that one, but they can't even spell "AGEIA" right in their references, so what do they know? :)

So anyway, I'll skip the swedish university stuff if you don't mind. I'm sorry, I don't have time to revisit whatever happened an eternity ago when Dynamechs and Tokamak were still around (!).

Then now 9 years later I see you repeating the same mistake and arriving to the same conclusions.

Look, I have no idea what "mistake" you're talking about :)

I didn't write an academic paper about Newton or something. The only "mistake" I apparently made was not using the "proper" version of either Newton or the integration code in PEEL, but that's really completely different from what you're describing here, and I didn't derive any special "conclusion" from it anyway.

has it occur to you that when you are writing a class for the first time you use what is available, and when you review over time you add new features as they show up. what the that has to do with profiling?

Usually when you're writing a class for the first time, you don't do it right away with SSE4. You just write a scalar version first, and then you rewrite in SIMD when everything works. If you rewrote in SIMD without profiling, I find that dangerous because there is no guarantee that the SIMD code will be faster than the scalar code. So, that's what it has to do with profiling.

one big difference between you and I is that I am not obsessed with being the fastest at all cost.

I am not obsessed, that's just a large part of my job in PhysX.

they work as they are designed to work.

Fair enough.

so in Newton 3.12 and lower the ball will roll down the ramp because it get a face contact

I understand your reasoning. But I think that would make certain mesh configurations fail (or rather, behave badly) when triangles are not properly connected. I can try to create a small PEEL test to double-check that. Not now though. We can come back to this later if you want.

there you go again, you formulate your own questions to answer your won presupposed answerers.

What question?

I'm not sure why you always react in this aggressive way. You were mentioning the stack size so I assume you got some stack overflow crash (otherwise I don't know what other problem you encountered). A typical cause for stack overflow is recursive functions. A typical solution is to rewrite without recursion. Without knowing more details that was a pretty reasonable suggestion, as far as I can tell.

If you didn't get a stack overflow from a recursive function, I have no idea why you had to increase the stack size define in Newton, or what it has to do with me/PEEL.

In Newton a collision Scene is simply a compound collision that can be seen as a single shape by the broad phase.

So that would be an "aggregate" for us, I suppose. And some other term I can't remember for Havok.

the reason I did not used it is because your tool is because you tool do not provide interface for that, does it?

I added support & test scenes for aggregates in the next PEEL version, yes. But it looks like the problem you encountered is unrelated. I am not sure what the problem is/was. In my "wrong" Newton integration everything seemed to work as expected...
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Pierre » Thu Jun 18, 2015 9:47 am

Since you asked to be enlighten, I made a small movie to explain why PhysX or Bullet are not really a physics engine the are it is a kinematic engine that resolve interpenetration. take a look at this movie

Ok now we're talking. This is more interesting than swedish universities.

I'm running out of time but I'll come back to you about it this evening (which is going to delay the new PEEL integration again but oh well).

For now I'll just say that I noticed these differences before, in a perhaps much simpler reproducible way. Just zoom on the bottom of the stack, and try to pull out one of the bottom boxes. In Newton, they are easy to pull out individually and you can do it without disturbing the stack. In PhysX, by default, it's a lot harder, and the bottom box will pull out other surrounding boxes with it. I think this is what you are talking about, right?
Pierre
 
Posts: 30
Joined: Tue Jun 16, 2015 4:40 am

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Thu Jun 18, 2015 10:57 am

Pierre wrote:
Since you asked to be enlighten, I made a small movie to explain why PhysX or Bullet are not really a physics engine the are it is a kinematic engine that resolve interpenetration. take a look at this movie

Ok now we're talking. This is more interesting than swedish universities.

I'm running out of time but I'll come back to you about it this evening (which is going to delay the new PEEL integration again but oh well).

For now I'll just say that I noticed these differences before, in a perhaps much simpler reproducible way. Just zoom on the bottom of the stack, and try to pull out one of the bottom boxes. In Newton, they are easy to pull out individually and you can do it without disturbing the stack. In PhysX, by default, it's a lot harder, and the bottom box will pull out other surrounding boxes with it. I think this is what you are talking about, right?

there you go again with your assumptions, actually not, it is the other way around.

The pick force code takes the different in position between the mouse in world space and then and covert that to an instantaneous force and torque to meat the condition that the relative velocity and acceleration between mouse and project position in the body is zero.
here is the code.
Code: Select all
   
void CalculatePickForceAndTorque (const NewtonBody* const body, dFloat timestep, dVector& force, dVector& torque)
          {
      force = dVector (0.0f, 0.0f, 0.0f, 0.0f);
      torque = dVector (0.0f, 0.0f, 0.0f, 0.0f);

      CriticalSection (&this->m_lock);
      if (((m_extLinearImpulse % m_extLinearImpulse) != 0.0f) || ((m_extAngularImpulse % m_extAngularImpulse) != 0.0f)) {
         dVector com;
         dMatrix matrix;
         dVector omega0;
         dVector veloc0;
         dVector omega1;
         dVector veloc1;
         dVector pointVeloc;

         dFloat invTimeStep = 1.0f / timestep;

         // calculate the desired impulse
         NewtonBodyGetMatrix(body, &matrix[0][0]);
         NewtonBodyGetOmega (body, &omega0[0]);
         NewtonBodyGetVelocity (body, &veloc0[0]);

         dFloat stiffness = 0.3f;
         dVector posit (m_extLinearImpulse);
         dVector deltaVeloc (m_extAngularImpulse);

         NewtonBodyGetPointVelocity (body, &posit[0], &pointVeloc[0]);
         deltaVeloc = deltaVeloc.Scale (stiffness * invTimeStep) - pointVeloc;

         for (int i = 0; i < 3; i ++) {
            dVector veloc (0.0f, 0.0f, 0.0f, 0.0f);
            veloc[i] = deltaVeloc[i];
            NewtonBodyAddImpulse (body, &veloc[0], &posit[0]);
         }

         // damp angular velocity
         NewtonBodyGetOmega (body, &omega1[0]);
         NewtonBodyGetVelocity (body, &veloc1[0]);
         omega1 = omega1.Scale (0.9f);

         // restore body velocity and angular velocity
         NewtonBodySetOmega (body, &omega0[0]);
         NewtonBodySetVelocity(body, &veloc0[0]);

         // convert the delta velocity change to a external force and torque
         dFloat Ixx;
         dFloat Iyy;
         dFloat Izz;
         dFloat mass;
         NewtonBodyGetMassMatrix (body, &mass, &Ixx, &Iyy, &Izz);

         dVector angularMomentum (Ixx, Iyy, Izz);
         angularMomentum = matrix.RotateVector (angularMomentum.CompProduct(matrix.UnrotateVector(omega1 - omega0)));

         force = (veloc1 - veloc0).Scale (mass * invTimeStep);
         torque = angularMomentum.Scale(invTimeStep);

         // reset the impulse accumulators for the next update
         m_extLinearImpulse = dVector (0.0f, 0.0f, 0.0f, 0.0f);
         m_extAngularImpulse = dVector (0.0f, 0.0f, 0.0f, 0.0f);
      }
   }


this will generates instantaneous forces of hundred of thousand off newton on the body, so strong that I have to put a limit of 5 digit is so that the solver get some digit left to work with.
this is why the pick code is snappy in newton regardless of how many other force are acting on he body. Physx can not do that, because it is not stable enough to support random forces of hundred of thousands of newton acting on a body.

For the record the fact the friction breaks in newton, that's the correct solution. this is why a wrecking ball punch a hole when it hits a wall instead of that continue smoggy behavior that you see in PhysX.
the smoggy behavior is the one the most erroneous behaviors there it.
The reason is that friction is discrete not continue, and since the instantaneous lateral force is much larger than the friction, that force in boxed close to the pulled body will break before others the force below, and before the box on top and on the side and so on.
This keeps going outward but at some point Kinetic friction takes place and prevent and that breaks pass very lithe force to the neighbor and the wave stops from propagating over the entire structure.

do not believe that go check out wrecking ball acting on a brick wall
https://www.youtube.com/watch?v=SgE8RIwpcSk
the either punch a hole of large piece break apart and fall as a whole.
this is such a typical behavior that it even can break trough steel stud.

you seem to think that I am a parlor trick Magician that is some how try to trick the entire world.
guess what I wish a was It is one hell more lucrative the this.
but it is much simple than just tricks, I just the math do the trick for me, and all the effect come as ass emerging behaviors, it might not be fast and some time I have to compromise it a little, but is it an amassing thing
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: As it turned out, the emperors had not cloth.

Postby Julio Jerez » Thu Jun 18, 2015 11:02 am

I tell you what, it you want to normalize the pick behavior, why don't you add a call back to PEEL that the application can call an the function will return either the force and the impulse the should be applied to the pick body. the you can add the same function you use to do the pick in the Physx plug it the Bullet plug it. that way you can gage the friction values.
Julio Jerez
Moderator
Moderator
 
Posts: 10989
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests