PhysX Fails, Newton Sails

[Pierre]

It is well-known that PhysX relies on "magic numbers" and approximations to get the behavior they want, while Newton is actually based on the real equations of Newtonian physics, right down to conservation of angular momentum.

Beware of "well-known" PhysX "facts" here again. Most of them are plain BS really.

 

All these engines are based on the same "real" equations of motion. They just use different ways to solve them, with different trade-offs depending on the target audience and/or customer requests.

 

There aren't more "magic numbers" in PhysX than in the others (unless you're talking about something specific that I am not aware of?). And I'd say they all use "approximations" as soon as they rely on iterative solvers that don't necessarily converge to the exact solution.

[Josh]

It would be interesting to see another build of the application with all simulators tuned for maximum stability.

[Crazycarpet]

First off amazing tool, I've been playing with it for days on end, and now with the new version.

 

While, I know there's lots of speculation on performance regarding PhysX when it's "CPU bound' but I get results that suggest that's very true when using PEEL... any chance you could shed light on this? When I use my computer with a dedicated GPU PhysX generally outperforms them all. (In average case.)

 

However, when I use my laptop that has on integrated chipset, Newton generally outperforms them all. (Again, in average case.) and by quite a large margin too. It seems to be the case for the vast majority of tests as well. (My last post was wrong, there's only a few demos where on my laptop PhysX performs the best.)

 

I'm just curious as to why PhysX generally performs so much better on my high-end machine, where as Newton although it performs better on my high end machine it doesn't take an immense jump in performance like PhysX... Is PhysX that much more taxing on the low-end CPU? PhysX also simulates rigidbodys on the GPU according to the GDC presentation. Would this not suggest that a CPU bound PhysX would be slower?

 

Is it fair to say PhysX performs significantly better on computers with discrete GPU's rather than ones with integrated chipsets as it uses GPU simulation? Maybe the term "CPU bound" is inaccurate to describe what I;m describing.

[Newton Dynamics]

Hello

I see that this topic touched a nerve at nvidia head quarters.

I need to rebut what Mr Pierre Terdiman is saying here but It seems I'm required to make a post and be approved before I can take quotes.

[Josh]

Welcome to the forum. I have to manually approve the first post of every account., otherwise this forum would be overrun with spam.

[Newton Dynamics]

Oh ok thanks,

before I start this is my second post, I am requesting that my user name to be edited to Newton Dynamics.

Julio

[Newton Dynamics]

Ok thank you.

Here we go.

 

I see mr Pierre is making a gross misrepresentation of not just Newton but of other engine as well.

In his first post he claims this:

 

Hi there,

 

I'm the guy who wrote PEEL. These videos (and Julio's PEEL master branch) unfortunately use an old work-in-progress version of PhysX 3.4. You can grab a more recent build here: https://github.com/Pierre-Terdiman/PEEL

 

There is a long history regarding Newton in PEEL. Let's just say there are two sides to every story.

 

- Pierre

 

the first thing is that Mr Pierre seems to have a chronological confusion here,

how could I be using a work in progress of Phsx 3.4 when the release date of PhysX 3.4 was January 2017?

http://www.physxinfo.com/files_new/PhysX_3-4_release_notes.html

and even the release date of previous version was January 2015

http://physxinfo.com/files_new/PhysX_3-3-3_release_notes.html

 

He is projection onto me what I accuse him of doing while he is refusing to acknowledge that at least in 2013 when they approached me to integrate Newton into peel, newton was a superior engine than PhysX in the large majority of their own test, they simply refused to include my integration and instead they peek a chose what made PhysX look good and reject the one that made PhysX not so good.

 

The last version they provided before they cut me off from source control was PhysX 3.3.1 and at that time compared side by side in most test Newton was the better solution but they in public suppressed the data.

 

Mean while ms Pierre and the PhysX pr people where making claims that PhycX was the undisputable champion on all these test when the knew well that the was false.

http://physxinfo.com/news/tag/peel/

http://www.codercorner.com/blog/?p=748

 

Now why does mr Pierre accuse me of using a version of Physx that did not even existed when I was working on that tool,

maybe it has to do with this conversation.

 

http://newtondynamics.com/forum/viewtopic.php?f=9&t=8836

in a post I told him this that he took a work in progress version of Newton 3.13 and use claim that is was crashing.

 

pierre said

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.

 

Julio replied

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.

no where there the existence of Physx 3.4 is mentioned.

 

Now some people will say what does it matters that the engine is integrated one way or the other, there is a new version that will include the new changes. and that will be reasonable expects that it will be incorrect.

For people how think that way I suggest you read this.

https://github.com/Pierre-Terdiman/PEEL/issues/3

 

The integration of Newton you get into peel is not the proper integration.

it is what the nee to do to make Newton and I believe the do to other 3 engines to make PhysX look superior.

 

Mr Pierre since to have this idea that all other engine most work the way PhysX works and what that doe not happened he changes other integration to fix his narrative. More on this on later post.

[Crazycarpet]

Intent aside, Newton performs great in PEEL and in many cases is more accurate than PhysX and on my computer that lacks a discrete GPU faster as well... I can certainly post the excel files if anyone isn't getting the same results.

 

What I'm more skeptical about is Bullet, I haven't worked at all with Newton so I can't speak on it... but I've done quite a lot of work with Bullet and I've never seen the funky behavior it has in some of the PEEL demos.

 

None-the-less I don't think PEEL intentionally aims to make any physics engine looks bad, however it does seem to have a bit of a bias towards PhysX as merely tweaking a few values can make the other engines provide the same results (well at least in Bullet). That being said it's also not fair to dismiss the results of PEEL as it's probably the most accurate test out there that compares such a wide array of physics engines. I feel like Pierre is most experienced with PhysX (correct me if I'm wrong) which would kind of implicitly cause a slight bias in the results. But I also think he makes this clear in his statements with comments like:

 

Generally speaking I wouldn't trust a video showing something *failing*, more often than not you can make things work by just tweaking the parameters (as least as far as the PEEL scenes are concerned) or using the proper engine feature

 

It can't be all bad I mean I personally disliked Newton for all the wrong reasons until I saw it in action in PEEL and I'm sure others who haven't heard about Newton in the past would feel the same way.

That being said it would be nice to see an up to date comparison of a test between PhysX 3.4 and Newton 3.14 that everyone can agree on as being "fair".Maybe in the near future this could happen?

[Newton Dynamics]

Now as far as PhysX is concerned, extra iterations there seem cheaper than for other engines. So for that torus scene, for example, you can increase the iterations quite a bit (say from 4 to 32) and get a behavior that become closer to Newton's (while possibly still being cheaper, YMMV depending on which versions you're using). In the latest released PEEL (1.1), I added something in the PhysX UI to configure it either for performance or accuracy. This changes the results quite a bit for some of the scenes, in particular for the ones that Julio cherry-picked in his videos

 

again this seem to be a behavioral pattern on mr Pierre Terdiman character, he takes what he does and project it onto others.

do not take my word for it, here he is accused of cherry picking his test and now he level the same accusation on me.

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=6&t=9095&start=15

 

Notice the date on that thread, May 2013, by that time Mr Pierre already had my 3.12 Newton integration but some how he forgot to mention that the same test he claimed physx was hundreds of times faster than Bullet, that Newton was tenth of times faster than Phsyx.

 

now why did I made those videos. the reason is that these were rebuttal to videos by Mr pierre where he claimed only PhysX can perform those demos and not other engine could. so given that almost no one would down load the version that Integrate Newton correctly and use the version that Mr Pierre think it should be, My only recourse is to make a video showing the results and even that seems to be too offensive to him.

The thing is that I do provide the source code for my integration, he does not. he provides the code of His integration of Newton into peel.

 

If mr Pierre was honest he would allow people to submit pool request but he does not, so there is not way I can integrate newton and reach the same audience, he audience have to trust his views of how people should evaluated newton and other competing engines.

Let me and any other developer be a contributor to peel in GitHub instead of you be the judge, the executioner and the jury of how other technologies should work at solving the same problems.

[Crazycarpet]

Let me be and any other developer be a contributor to peel in GitHub.

 

That really would be nice, as no matter how hard you try most likely the solutions implemented aren't always going to be the "best" possible solution for each physics engine. I don't think anyone is capable of knowing all the tricks and details of every physics engine. Is this planned at all or?

 

The reality is for a test to be fair it has to be open to everyone in every way, so the results can be falsified. But again, I think intentional bias is unlikely.

[Newton Dynamics]

moving on.

All engines use approximate "linear solvers", so both the performance and accuracy will depend on the number of iterations you choose. Then, they don't all use the same algorithms under the hood: you can have Gauss-Seidel, Jacobi, conjugate gradient, etc. These methods have pros and cons, and in particular they don't all converge at the same rate. So using the same number of iterations for all engines is not guaranteed to produce similar results in terms of accuracy.

 

It was a bit of a problem for me in PEEL: what default parameters should I use? Bullet for example uses 10 iterations by default these days, while PhysX uses 4. So if use 4 iterations for everybody "to be fair", I'm artificially decreasing the accuracy of Bullet compared to what a fresh user would get out-of-the-box, using its default parameters. And on the other hand, if I use Bullet's default values, I can be accused of being unfair since some engines will now use more iterations than others. This is a tricky thing.

 

In any case:

 

- you can improve PhysX's accuracy by increasing the number of iterations in the UI. This will make it slower.

 

- you can improve Newton's performance by decreasing the number of iterations in the UI. This will make less accurate.

 

 

I do not know what mr Pierre mean by "Linear solver" and why he assumes all engine are using that.

that's certainly not what News does. Newton uses an exact Danzig linear complementarity solver to calculate joint reaction forces,

and a matrix splitting version of Gauss Siedel to solve contacts together with joints.

 

Again mr Pierre is projecting, he thinks that because they use one method, that every one else is doing what the do which is a fallacious argument.

 

Notice how mr Pierre thinks that he can increase the number of Iteration to approach newton simulation quality, and when the does not works, he wants to lower the iterations in newton to decrease newton quality.

 

my question is this. How many people here wants to set the engine to the lower quality?

That seem to be a peculiar way to make your technology look better by make the competitor to look bad.

how about this? letting every developer select the settings the make thinks are best for his technology.

[Pierre]

First off amazing tool, I've been playing with it for days on end, and now with the new version.

 

While, I know there's lots of speculation on performance regarding PhysX when it's "CPU bound' but I get results that suggest that's very true when using PEEL... any chance you could shed light on this? When I use my computer with a dedicated GPU PhysX generally outperforms them all. (In average case.)

 

However, when I use my laptop that has on integrated chipset, Newton generally outperforms them all. (Again, in average case.) and by quite a large margin too. It seems to be the case for the vast majority of tests as well. (My last post was wrong, there's only a few demos where on my laptop PhysX performs the best.)

 

I'm just curious as to why PhysX generally performs so much better on my high-end machine, where as Newton although it performs better on my high end machine it doesn't take an immense jump in performance like PhysX... Is PhysX that much more taxing on the low-end CPU? PhysX also simulates rigidbodys on the GPU according to the GDC presentation. Would this not suggest that a CPU bound PhysX would be slower?

 

Is it fair to say PhysX performs significantly better on computers with discrete GPU's rather than ones with integrated chipsets as it uses GPU simulation? Maybe the term "CPU bound" is inaccurate to describe what I;m describing.

 

I am not sure I entirely follow your questions but let me try to answer them.

 

First, just so we're clear, by default (if you just run PEEL and don't tweak anything), everything uses the CPU. Nothing runs on the GPU (except the basic OpenGL graphics of course). In that mode, as far as I saw, there is no major difference between running on a desktop PC or running on a laptop. The relative performance of each engine should remain the same. If you do see a difference, then this is something I didn't see myself and cannot explain. Some things that come to mind nonetheless:

 

- make sure both the desktop and laptop use the same "power plan" (in the control pannel). There's usually a "high performance" plan which is better for running benchmarks, as opposed to e.g. a "power saving" plan.

 

- make sure you are not using more worker threads than the number of physical available cores. For example if the desktop PC has 4 cores, the laptop 2 cores, and you run with 4 threads in PhysX, maybe it creates some issues.

 

- try to run one engine at a time instead of both at the same time (or use the Fx keys to disable an engine). Maybe the first one takes a huge amount of cache misses compared to the second. Alternatively there is a checkbox to randomize the order in which engines are used.

 

- try to disable rendering, just in case.

 

If the difference remains, then I don't know how to explain it, and I would need to use a profiler on your laptop to go to the bottom of it. Another thing that comes to mind here is that maybe the desktop PC is Intel and the laptop isn't. We only really test the performance on Intel processors. You can use the CPU-Z tool to dump your processor's characteristics to a file, and I can have a look if you want.

 

 

Now, the GPU stuff.

 

At time of writing, only PhysX 3.4. uses the GPU in PEEL. And this only happens if you click the "use GPU" checkbox in the PhysX plugin's UI. If you do that, the rigid body simulation will then run on the GPU. Things like articulations and scene queries (raycasts, etc) stay on the CPU (they haven't been ported to the GPU yet).

 

The GPU code is written in CUDA, so it will only run on an Nvidia graphics card. If your "integrated chipset" is not Nvidia, there should be an error message in the DOS window telling you that the software reverted to the CPU pipeline. It should not affect performance compared to not selecting the "use GPU" checkbox but who knows, maybe there's a bug in that specific scenario.

 

If you integrated chipset is an Nvidia card, and you do run the physics on the GPU there, it might be slow simply because the GPU is too old. There is a break-even point with the GPU stuff, beyond which the GPU codepath is faster than the CPU codepath. But it is not always the case. Simple scenes will typically run faster on the CPU no matter what. And for large scenes, "old" GPUs may also not run the simulation faster than the CPU. You need a heavy scene and a relatively recent GPU for the GPU codepath to be a gain. If needed, CPU-Z will tell you what exact GPU you have, and I can have a look. If you are running on the GPU, the performance might also depend on the driver version. Downloading the latest drivers might help here, if you're not up-to-date.

 

That's about all I can think of, I hope it answers the questions a bit.

[Pierre]

What I'm more skeptical about is Bullet, I haven't worked at all with Newton so I can't speak on it... but I've done quite a lot of work with Bullet and I've never seen the funky behavior it has in some of the PEEL demos.

Please look at the Bullet plugin's code and suggest improvements. I am certainly not an expert with Bullet, and what is provided in PEEL is a "best effort". I asked Erwin (Bullet's main author) to send improvements but he only contributed some minor tweaks that got integrated but didn't really change the results much.

 

So far my main problem with Bullet is that when I change the settings to make a particular test behave better, it makes things worse in some other tests.

 

 

None-the-less I don't think PEEL intentionally aims to make any physics engine looks bad

Indeed, if there are some issues and mistakes they're not intentional. No matter what people claim. It would be a weird strategy to make things intentionally bad for engine X, and then open source the whole thing.

 

 

however it does seem to have a bit of a bias towards PhysX as merely tweaking a few values can make the other engines provide the same results (well at least in Bullet).

Yes, that was what I saw as well for a few of them. But as mentioned above, the tweaks I could find for a given test were usually different from the tweaks needed in another scene, making each change questionable.

 

In any case, please suggest any improvements to the Bullet plugin, they're certainly needed.

 

 

I feel like Pierre is most experienced with PhysX (correct me if I'm wrong) which would kind of implicitly cause a slight bias in the results.

Ah yes, if you didn't know, I am an Nvidia employee and I wrote some parts of PhysX. I also wrote half of the NovodeX SDK back in the days. PEEL is certainly slightly biased in that respect, since I know PhysX a lot more than the other engines. However, this is the reason why it's open source: please suggest improvements for the other engines. They are very welcome.

 

 

I personally disliked Newton for all the wrong reasons until I saw it in action in PEEL and I'm sure others who haven't heard about Newton in the past would feel the same way.

I can only hope that Julio will pay attention to this bit and give me some credit.

 

 

That being said it would be nice to see an up to date comparison of a test between PhysX 3.4 and Newton 3.14 that everyone can agree on as being "fair".Maybe in the near future this could happen?

I tried multiple times, but no matter what I do Julio is increasingly unhappy and aggressive. I kind of gave up now. I was last considering removing Newton from PEEL entirely, since I only ever got insults and unfounded accusations out of it. I suspect this is going to happen again in this thread, unfortunately.

[Newton Dynamics]

Also, last time I tested it (at the time of the PEEL 1.1 release), Newton 3.14 had an issue with the "sleeping" algorithm (the thing that deactivates objects when they are not moving much). By default these mechanisms are disabled in PEEL, so that I can have a look at the real performance / stability of each engine. That is, nothing ever sleeps, nothing is ever deactivated (so that's not what you'd get in a real game). However the API for controlling this seemed broken in Newton 3.14, i.e. I couldn't deactivate sleeping anymore (compared to Newton 3.13 for example). That gave Newton 3.14 a bit of an unfair advantage in some scenes IIRC, since it was the only engine for which things went to sleep. Box stacks typically go to sleep immediately, so maybe it could have an effect here.

 

Mr Pierre here is just playing a script he can not possible believe, I am sure more than one person here can verify by experience that "sleeping can't be disabled in newton" is simply not true.

This is not the first time Mr Pierre accuse me of the same thing and is not the only place either, he does in many other forums where the sleep issue is raised.

Sleeping is not disabled in 3.14, 3.13, or any other versions of newton.

I have corrected him and he acknowledge that the sleep was indeed disable, but he ignored and he goes back to the same script.

http://newtondynamics.com/forum/viewtopic.php?f=9&t=8836&start=15

 

what ms Pierre does not understand is that that when you set a pile of objects in which all external force are constant. in general the array will reach an equilibrium state.

 

what happens is that a solver first will take many iteration called pivoting until it find a set of forces that keep the stack up. In a danzing solver this works like this.

first it tries to find a set of forces that satisfy the solution, if the forces the first set of forces fail,

using some strategy they it select a force and remove from the solution set. and try again.

it keeps doing that until is find the minimal set of forces that sastisfy the configuration.

the method of removing and adding a force is called pivoting and it is the part the makes a solver slow.

 

In newton at first the solver does all that work, but the after few frames because the calculated set for forces is exact within a numerical tolerance, the stack go to equilibrium very quickly.

since there are not new forces added to the set, subsequence calls do very few pivoting passes and this is what mr Pierrre interpreted as Newton going to sleep.

 

For the people who are confused but the explanation, here is an analogy.

 

imagine you are sorting an array of random numbers using insertion sort.

when you run the array the first time, if you let it run to the end it will take a long tome to do the job.

however if you try to sort the same array that was already sorted, the same algorithm does in one pass.

this is what Mr Pierre keep misrepresenting and "Newton do no allow to disable sleep)

 

he is confusing, no doin anything when sleep is active with and algorithm having a time complexity

of O(n) best case and O(n^2) worse case.

In the case of newton when stack is up, it takes an O(n) to get the same solution that was the set as the first guess. which is very different that not doing anything.

 

The reason this does not works on engines like Physx is because the do not iterate until the error is drive to zero, instead they iterate a fix number of time and terminate with a large error that the need to fixed by teleporting the bodies with position correction passes)

 

some how a functionality that should be a good thing, mr Pierre present it as a bad thing, no only that, he misrepresent the competitors.

[Pierre]

how could I be using a work in progress of Phsx 3.4 when the release date of PhysX 3.4 was January 2017?

Because I released a preview of PhysX 3.4 as part of PEEL 1.01, on April 8, 2015. See here:

https://github.com/Pierre-Terdiman/PEEL/releases

 

If you download your own PEEL-master, you will see that it contains the same DLLs, from the same day. As I was saying, this is an old version of PhysX 3.4 that contained regressions (as noted in the PEEL readme at the time), and was also very different from the one released in January 2017. The whole pipeline has been revisited and turned upside-down for the GPU rigid bodies since then.

 

Thus, I'm afraid the confusion is not on my side.

 

 

he is refusing to acknowledge that at least in 2013 when they approached me to integrate Newton into peel, newton was a superior engine than PhysX in the large majority of their own test

I suggest you read John's email again, copy-pasted in this very thread. It said right there that Newton was better for some things. So I have no idea what you are complaining about. (For readers: this has been a recurrent pattern in my discussions with Julio, most of the time I'm lost, I don't understand what he wants or what he says).

 

In any case if I run your own PEEL-master branch that I just downloaded again, and compare Newton 3.13 to PhysX 3.3 (the most recent versions in there), I see the same as the hundred times I've looked at it, and the same as what people already reported in this thread: in some ways Newton is better, in some ways it's PhysX. As I explained before in this thread again, there is no "best" engine, it's a multi-dimensional thing.

 

I am not sure what more you want me to say.

 

 

 

they simply refused to include my integration

This is just incorrect.

 

I know nothing about Newton. The only time I tried to write a Newton plugin for PEEL myself, I couldn't even get the collision detection to work (sorry but there's no doc and the API is not super clear to me). As a result, so far, all Newton plugins came directly from you. It is your own integration. As I wrote N times in the past, if you don't like it, just send me a new one.

 

 

Mean while ms Pierre and the PhysX pr people where making claims that PhycX was the undisputable champion on all these test when the knew well that the was false.

http://physxinfo.com/news/tag/peel/

http://www.codercorner.com/blog/?p=748

 

As explained by John Ratcliff on GitHub in a link that you posted yourself (https://github.com/Pierre-Terdiman/PEEL/issues/3), the Newton integration provided in PEEL 1.0 was the last one I ever got.

 

You complained about it (see that link). I went to your forum, you sent a new one, released in PEEL 1.1. And you complained again anyway, for reasons that I never fully understood.

 

As for my blog post, it was written before the first Newton integration in PEEL happened so I have no idea why you bring that up. It was mainly an answer to the online claims that "PhysX is crippled". It has absolutely nothing to do with Newton.

 

This is weird and surreal to me: what would you want me to have written in that blog post, before I even used Newton for the first time? It is irrelevant anyway: am I not allowed to claim that PhysX is the champion if I want to, in exactly the same way you constantly claim Newton is? I truly don't get it.

 

 

Now why does mr Pierre accuse me of using a version of Physx that did not even existed when I was working on that tool,

Because as I showed above, you are indeed using an old version. And the words are important: I did not "accuse" you of it, I just pointed out this fact. Not looking for conflicts here.

 

 

 

http://newtondynamics.com/forum/viewtopic.php?f=9&t=8836

I certainly encourage people to read that one, for some context and background. I don't think I said anything bad in there, but I will let people be the judges of that.

 

 

 

 

The integration of Newton you get into peel is not the proper integration.

it is what the nee to do to make Newton and I believe the do to other 3 engines to make PhysX look superior.

As I wrote N times on your own forum, including in a thread that became so bad it got deleted, I suggest you just send me a new one instead of insulting me all the time.

 

If this is too much to ask, please politely point out one thing that I should change in the current code.

[Pierre]

again this seem to be a behavioral pattern on mr Pierre Terdiman character, he takes what he does and project it onto others.

do not take my word for it, here he is accused of cherry picking his test and now he level the same accusation on me.

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=6&t=9095&start=15

I encourage people to read the full thing and decide for themselves if it is comparable. (It is not)

 

 

Notice the date on that thread, May 2013, by that time Mr Pierre already had my 3.12 Newton integration but some how he forgot to mention that the same test he claimed physx was hundreds of times faster than Bullet, that Newton was tenth of times faster than Phsyx.

That is just ridiculous. I never got any 3.12 integration from you, to start with. I did that one myself from the 3.13 plugin you provided, long after the 3.13 one was done. I wanted to see if there was any difference. And regardless, I am not supposed to speak about Newton in all my posts, am I? And even if I "forgot", so what? Are you mentioning the tests where PhysX in faster in discussion involving two other unrelated engines? What the hell?

 

 

where he claimed only PhysX can perform those demos and not other engine could

I never claimed such a thing. You keep repeating this but you never provide any source. I just never claimed that only PhysX could do X or Y. Especially when Havok usually performs just as well or better.

 

 

The thing is that I do provide the source code for my integration, he does not. he provides the code of His integration of Newton into peel.

I'm afraid you lost me again. I provide the source code for everything, no idea, no idea what you mean.

 

 

If mr Pierre was honest he would allow people to submit pool request but he does not, so there is not way I can integrate newton and reach the same audience, he audience have to trust his views of how people should evaluated newton and other competing engines.

Let me and any other developer be a contributor to peel in GitHub instead of you be the judge, the executioner and the jury of how other technologies should work at solving the same problems.

 

You are already a contributor. I am not the one who wrote the Newton plugins. I only removed offensive comments about the "abomination of PhysX materials" (sigh) and bits that were not supported by other engines. I did not affect the Newton performance or memory usage.

 

You can tell me what to change or submit new versions of the code, as I wrote a zillion times.

 

You can also grab the whole thing on GitHub and do your own version, as you (and others) did. Not sure what more you want

[Pierre]

I do not know what mr Pierre mean by "Linear solver" and why he assumes all engine are using that.

Linear-time solvers, i.e. iterative solvers, as opposed to the old-school exact solvers like the LCP-based ones from Baraff.

 

I am not assuming anything. Bullet, PhysX, Havok, and recent versions of Newton all use iterative solvers. Newton still has an option to enable the exact one, but this is not the default IIRC.

 

and a matrix splitting version of Gauss Siedel to solve contacts together with joints.

GS = iterative = what I meant

 

 

Again mr Pierre is projecting, he thinks that because they use one method, that every one else is doing what the do which is a fallacious argument.

Can you please stop? Your own API had parameters for the number of iterations, etc.

 

 

Notice how mr Pierre thinks that he can increase the number of Iteration to approach newton simulation quality, and when the does not works, he wants to lower the iterations in newton to decrease newton quality.

What? That's not at all what I said.

[Pierre]

this is what Mr Pierre keep misrepresenting and "Newton do no allow to disable sleep)

Ok, so it is not a bug but a feature. It's an easy mistake to make since:

 

- as you pointed out, it's not the first time it happens. This stuff was broken in the past, before you fixed it.

 

- the API to control the sleeping behavior is still there unchanged. But when upgrading from 3.13 to 3.14 the behavior changes a lot in that respect, and it looks like the call has no effect anymore.

 

In any case the net result is that I cannot really test the performance of Newton against the others like I did before.

[Josh]

Thanks everyone for contributing to this discussion. Very interesting stuff.

[Newton Dynamics]

Indeed, if there are some issues and mistakes they're not intentional. No matter what people claim. It would be a weird strategy to make

things intentionally bad for engine X, and then open source the whole thing.

No mr Pierre, I too know a little about statistics and random variables, if you have a dice that every time you role it land on six,

you know that the dice is probably loaded.

The one constant here is that all the mistakes happens to favor physx and penalized every one else.

but it is much worse that than.

you were presented with correction in more than one occasion.

First you have that code in some source control data base that Radcliff somehow said he never integrated.

Let us say that was right and the integration just got lost.

 

After you decided to go public, I submitted my integration to you and we had a conversation about that. and you said you were going to integrated my implementation. do you remember?

https://github.com/Pierre-Terdiman/PEEL/issues/3

 

them you silently closed the topic as if it never happened. Not only you closed the topic you went over my integration and changed in a way that any user would think I was the one who made the changes to my own integration.

here is an example if you compare the files in the archive that I present to mr Pierre to the one in the GitHub download you will fiund many places where the code has a comment //Julio

I show one for the capability file.

 

 

void NewtonPint::GetCaps(PintCaps& caps) const
{
caps.mSupportRigidBodySimulation = true;
caps.mSupportKinematics	= true;
caps.mSupportCollisionGroups  = true;
caps.mSupportCompounds	= true;
caps.mSupportConvexes	= true;
caps.mSupportMeshes	 = true;
caps.mSupportMassForInertia   = true;
//JULIO
// caps.mSupportCones	 = true; 
caps.mSupportCylinders	= true;
// caps.mSupportTaperedCylinders  = true;
// caps.mSupportTaperedCapsules  = true;
// caps.mCollisionUniformScaling  = true;
// caps.mCollisionNonUniformScaling = true;
caps.mSupportSphericalJoints  = true;
caps.mSupportHingeJoints   = true;
caps.mSupportFixedJoints   = true;
caps.mSupportPrismaticJoints  = true;
caps.mSupportArticulations   = true; 
caps.mSupportDistanceJoints   = true;
//JULIO
// caps.mSupportRelationalJoints  = true;
// caps.mSupportCylindricalJoints  = true;
// caps.mSupportUniversalJoints  = true;
caps.mSupportPhantoms	= true;
caps.mSupportRaycasts	= true;
caps.mSupportBoxSweeps	= true; 
caps.mSupportSphereSweeps   = true; 
caps.mSupportCapsuleSweeps   = true; 
caps.mSupportConvexSweeps   = true; 
caps.mSupportSphereOverlaps   = true; 
caps.mSupportBoxOverlaps   = true; 
caps.mSupportCapsuleOverlaps  = true; 
caps.mSupportConvexOverlaps   = true; 

caps.mSupportChamferedCylinders  = true;
caps.mSupportExtraConstraintHacks = false;
// caps.mSupportVoronoidDecompositionGeneration = true; 
}

 

you when out of your way to removed the changes you did not want and you place my name of them, can you explain why would I add a comment to remove functionality?

 

you said that there are not more magic numbers more than what other engines do, but I can tell you I do not know of anybody doing this.

taken from

pierre said: Now, this alternative approach has some issues that should be mentioned. First, for obvious reasons creating the constraints multiple times will use more memory. And second, the effect will depend on the order in which the constraints are created. For example say you have constraints 1 to N, and you want to create them 4 times. If you create them from 1 to N and repeat the sequence from scratch 4 times, it will work better than creating 4 times the same constraint before switching to the next. In other words, 1234..N1234..N1234..N1234..N is better than 1111222233334444..NNNN. This is semi-obvious but worth pointing out. For the same reason, this trick does not work equally well in all physics engines: some of them reorder constraints in arbitrary ways, etc. You can use PEEL 1.1 to check and explore how different engines react to this approach.

to me that kind of calibration look like voodoo magic, but maybe you have a more technical term for it.

 

I do not mind if you do it to make your stuff look the best it could, but that is not the only thong you do.

When I download the GitHub version, not only I see new getting worse and worse, it is also getting orders of magnitude slower.

so I look at the code.

guess what this is what I found you said you have a UI but in code does not do what the UI said. for example in the toroid case

FixedJointsTorusMultipleConstraints and FixedJointsTorus you applied same hacks to all other engines that you apply to physx.

 

don't you find a least disingenuous that a test that is supposed to improve quality act just the opposite? why are we obligated to support the PhysX hacks. I tell you why? because if you do not force othe engine to execute the same hacks then as PhysX quality improves performance will go down and you can't have that, can you? so your solution Is that other engine must resolve four, eight and some time even 32 times the same joints load so that PhysX is still faster.

 

you do same thing for other demos where every one is using a normal initial mass matrix you hard code PhysX to have the Inertia artificially multiplied by ten and still PhysX is less stable.

 

 

I can only hope that Julio will pay attention to this bit and give me some credit.

...

 

I tried multiple times, but no matter what I do Julio is increasingly unhappy and aggressive. I kind of gave up now. I was last considering removing Newton from PEEL entirely, since I only ever got insults and unfounded accusations out of it. I suspect this is going to happen again in this thread, unfortunately.

credit for what for spending a generation misrrepsenting every body.

you call me aggressive, but we you objects is to be exposed in you hypocrisy.

 

Because I released a preview of PhysX 3.4 as part of PEEL 1.01, on April 8, 2015. See here:

Am I the only one who thinks that 2013 come before 2015?

 

aren't you forgetting something? Peel was not a public tool I could not have any of those tool only some one from nvidia gave them to me.

Peel is a tool nvidia use to show potential costumer how good PhysX is compared to the competition.

there reason Newton is there is because by an accident I just happen to work with ratclift with the same studio and he was embarrass at how poor the integration for newton was and I assume the same is true for other developers.

 

Beside the archive that is on the download links Newton 3.13, so in any case in comparing and older version of newton to all versions of PhysX up to 3.4 (work in progress)

would you admit that in am case if better that all version at that time? but you can't admit it can you.

you excuse is that I am using a lees that latest version, but you have been said the same since physx 2.8 haven't you?

 

As I wrote N times on your own forum, including in a thread that became so bad it got deleted, I suggest you just send me a new one instead of insulting me all the time.

 

If this is too much to ask, please politely point out one thing that I should change in the current code.

that would be a fool errand, I already provided tow versions. one you have in your source control, and one I poste in your GitHub and you ignored it. why would I do the same all over?

 

Like I said before if you were honest, you would allow for people to be contributor to the GitHub source control.

let every stablished developer who want to do so, contribute what they believes is the best for their technology,

you can always veto a bad contribution.

Instead ask for people to give you contribution so that you can pick and shoes what to present.

[Newton Dynamics]

Linear-time solvers, i.e. iterative solvers, as opposed to the old-school exact solvers like the LCP-based ones from Baraff.

 

I am not assuming anything. Bullet, PhysX, Havok, and recent versions of Newton all use iterative solvers. Newton still has an option to enable the exact one, but this is not the default IIRC.

this is like saying every swamp are white until you find a black swamp.

 

GS = iterative = what I meant

...

Can you please stop? Your own API had parameters for the number of iterations, etc.

wrong again, with newton 3.12 and 3.13 I briefly experiment with iterative solver but I realized that was a big mistake so I went back to the exact solver only solution and see how it can be adapted the solver to treat joints together as if they were a single block.

while leaving the contact to the iterative solver. so not the in newton solver iteration do nothing to joint you can have one joint it 1000 joint and the are all solved together at once whenever they can be resolve as an acyclic graphs.

so not newton is not like Bullet, PhysX or Havok.

[Newton Dynamics]

you say this.

If you download your own PEEL-master, you will see that it contains the same DLLs, from the same day. As I was saying, this is an old version of PhysX 3.4 that contained regressions (as noted in the PEEL readme at the time), and was also very different from the one released in January 2017. The whole pipeline has been revisited and turned upside-down for the GPU rigid bodies since then.

 

Thus, I'm afraid the confusion is not on my side.

 

and you conclude with this.

In any case if I run your own PEEL-master branch that I just downloaded again, and compare Newton 3.13 to PhysX 3.3 (the most recent versions in there), I see the same as the hundred times I've looked at it, and the same as what people already reported in this thread: in some ways Newton is better, in some ways it's PhysX. As I explained before in this thread again, there is no "best" engine, it's a multi-dimensional thing.

 

so the statement you made before that I took a work in progress version for PhysX 3.4 was not really true was it?

I know my English is not very good and for that I apologize, but I understand enough to figure out those two statements contradict each other.

The problem that happens with you Pierre, is that you keep grasping to any straw in order to keep making excuses and never admit any wrong doing.

The truth was that I worked with what you guys gave me back on 2013 long before peel was public.

when you released Peel in GitHub two years later, I downloaded to get the latest but I was not able to use any of the new stuff because Peel comes with a set of compiled libraries that prevent any end users from extending it to make new test.

The result is that I got the new data and some of the new source code but I was not abled to use the so called work in progress of 3.4 because that was a dll you put there the same day.

 

It also debunks the statement that you never use Newton because you not understand it, I mean you are saying you looked at it hundreds of time, how could this be?.

No mr Pierre, I do not trust a word coming out from you, you may call it an insult, but I call it distrust of your hypocrisy.

[Pierre]

The one constant here is that all the mistakes happens to favor physx and penalized every one else

 

I am not sure which "mistakes" we are talking about here, but people only notice the bad stuff anyway. They ignore all the things that are done properly. So of course, if you only ever mention the problems, you end up with a biased view. Much like with the media only reporting the one plane that crashed, never the thousands of planes that did not.

 

 

you were presented with correction in more than one occasion

 

I did use the "correction". I have no idea why you keep denying this.

 

If I compare the code from your own PEEL-master branch and the one I have in PEEL 1.1, I even see optimizations that I added to make Newton perform better:

 

// PT: added this to discard kinematic-kinematic pairs. Without this the engine's perf & memory usage explodes in some kinematic scenes.
{
const PinkRigidBodyCookie* BodyCookie0 = (const PinkRigidBodyCookie*)NewtonBodyGetUserData(body0);
const PinkRigidBodyCookie* BodyCookie1 = (const PinkRigidBodyCookie*)NewtonBodyGetUserData(body1);
if(BodyCookie0->mIsKinematic && BodyCookie1->mIsKinematic)
return 0;
}

 

Why aren't you ever mentioning that ?

 

 

and you said you were going to integrated my implementation

 

And I did. That's why the Newton plugin's code is very different between PEEL 1.0 and PEEL 1.1.

 

 

them you silently closed the topic as if it never happened.

 

I closed the topic because it was resolved. I did use your latest version. If what you have in your PEEL-master branch is actually not the latest version, then I don't know where to grab it. I never got anything more than this.

 

 

Not only you closed the topic you went over my integration and changed in a way that any user would think I was the one who made the changes to my own integration.

 

No. We already discussed this on your own forum. You just ignore my explanations and constantly come back to this. You are the only one thinking that somehow "//JULIO" is worse than "//PIERRE". I used this comment to mark the places where I was removing the code that was not compiling or not called anymore. I never thought for a second that anybody could interpret it the way you did. And even if people think that you are the one who commented out these bits, I still have no idea why it matters. They would not be used even if they would be put back. I have no idea why you're upset about this.

 

 

you when out of your way to removed the changes you did not want and you place my name of them, can you explain why would I add a comment to remove functionality?

 

I already explained everything several times. It is still right there on your own forum: http://newtondynamics.com/forum/viewtopic.php?f=9&t=8839

 

This part:

 

the new shapes should be implemented for all engines supporting them (Havok, Bullet, etc). I don't know how much work that is, so I may remove this for now and keep that for a later version. Same for the new joints.

 

I told you exactly what I would change before doing it. I invite people to read the whole thread there and see for themselves.

 

 

to me that kind of calibration look like voodoo magic, but maybe you have a more technical term for it.

 

First, this is a trick done entirely on the user's side. This is not something built in PhysX itself. Nobody is forcing people to use this trick. Most PhysX games do not. PEEL 1.0 did not do any of that, and it didn't prevent PhysX from working. Thus, using this example to show that PhysX uses "magic numbers" is wrong.

 

Second, as I already explained on your own forum, this is simply an alternative way to increase the number of solver iterations. The number of solver iterations is not a "magic number", it is a legitimate and reasonable parameter coming from, well, iterative solvers.

 

At its core, this is simply an optimization. The direct way to do this would be to increase the number of solver iterations. But in PhysX it affects all objects contained in a "simulation island", which is bad for cases like this:

 

In this case, where a jointed object is in the middle of a large simulation island, the trick I presented gives better performance, because it limits the increased number of iterations to the jointed object itself, without affecting the debris / rocks around it.

 

It allowed us to run the scene on the GPU with good performance. You can call this "voodoo magic" if you want, but this isn't really more questionable than a solver iteration count.

 

 

for example in the toroid case

FixedJointsTorusMultipleConstraints and FixedJointsTorus you applied same hacks to all other engines that you apply to physx.

 

I have again no idea why this is a problem.

 

The FixedJointsTorus scene does not use the "hack", it is the same as before in PEEL 1.0. It does not penalize other engines.

 

Then FixedJointsTorusMultipleConstraints uses the hack, and the test description is pretty clear about it and nicely explains what this is about. Of course I run this in "all other engines", since that's the whole point of PEEL. This tool is made to investigate how different engines react to the same setup. And PEEL shows that it also works fine in Bullet, for example. It is perfectly legitimate and justified to try this in all engines.

 

 

don't you find a least disingenuous that a test that is supposed to improve quality act just the opposite?

 

It works in some engines, it doesn't work in others. What am I supposed to do about this? Remove the entire idea and tests from PEEL just because Newton reacts badly to it? With all due respect, that doesn't make any sense.

 

 

why are we obligated to support the PhysX hacks.

 

You are not "obligated". I did not support Newton in PEEL originally (see e.g. the list here: http://www.codercorner.com/blog/?p=748)

 

You complained about that. I only added Newton because you complained. But if you prefer, I can now remove Newton from PEEL for the same reasons.

 

Beyond that, the "PhysX hacks" are useful in more than just PhysX (I even got some of them from the Havok samples) so it is perfectly reasonable to try them in all engines.

 

 

so your solution Is that other engine must resolve four, eight and some time even 32 times the same joints load so that PhysX is still faster.

 

All the engines have to resolve N times the same joints in these tests, yes. That's the purpose of the tests: to see how each engine reacts to this approach. This is not to make PhysX "look faster" (?), this is to show how each engine reacts to a given strategy.

 

If an engine like Newton does not need to use this approach (e.g. because it uses a direct solver for joints), then this is going to be visible in the version of the test that does not use the hack, or when unchecking the appropriate checkbox in the per-test UI.

 

Your users are going to see this, they are not dumb. In this very thread you have one guy who played with PEEL (both your version and the latest one), and concluded that Newton was best for his use case. PEEL does not push people away from Newton. This very thread we're in shows you the opposite. I suggest you focus on this proven, real benefit from PEEL, rather than focusing on imaginary drawbacks.

 

 

you do same thing for other demos where every one is using a normal initial mass matrix you hard code PhysX to have the Inertia artificially multiplied by ten and still PhysX is less stable.

 

There should be a cap bit for the inertia tweak. Engines not supporting the feature should not be able to run the test.

 

Inertia tweaks are part of the bread and butter of game physics. It is legitimate to test these things.

 

In any case if "PhysX is less stable", I'm not sure why you're complaining. That does not penalize Newton, does it?

 

 

credit for what for spending a generation misrrepsenting every body.

you call me aggressive, but we you objects is to be exposed in you hypocrisy.

 

What?

 

 

Am I the only one who thinks that 2013 come before 2015?

 

What?

 

 

Beside the archive that is on the download links Newton 3.13, so in any case in comparing and older version of newton to all versions of PhysX up to 3.4 (work in progress)

 

What?

 

 

would you admit that in am case if better that all version at that time? but you can't admit it can you.

you excuse is that I am using a lees that latest version, but you have been said the same since physx 2.8 haven't you?

 

What?

 

I'm afraid you lost me again. I was only pointing out that your video uses an old version of PhysX 3.4. I have no idea how what you answered relates to this.

 

 

that would be a fool errand, I already provided tow versions. one you have in your source control, and one I poste in your GitHub and you ignored it. why would I do the same all over?

 

I did not ignore it. And if you don't want to submit improvements, don't complain about the state of the code.

 

 

Like I said before if you were honest, you would allow for people to be contributor to the GitHub source control.

 

And as I said, you're already a contributor. I have no idea about the "GitHub source control" stuff, I only use GitHub as a way to share the source code with the world. Never used GitHub before. The PEEL trunk is not on GitHub, it's on my desktop PC at home. That's why the GitHub depot has only 6 commits. I wouldn't even know how to "allow people to be contributor to the GitHub source control". But it probably wouldn't work anyway because half of PEEL is not actually on GitHub (the Havok binaries, other engines that I'm not supposed to release publicly, etc). I have to make all contributions somehow "work" with these other non-public bits as well. That does not prevent people from sending contributions and improvements (as Erwin did for Bullet).

 

 

Instead ask for people to give you contribution so that you can pick and shoes what to present.

 

Nonsense. That's exactly why I added the //JULIO comments. I could have silently removed these pieces of code, but I left everything as-is to show what was left out.

 

No matter what I do, you complain.

 

 

wrong again, with newton 3.12 and 3.13 I briefly experiment with iterative solver but I realized that was a big mistake so I went back to the exact solver only solution

 

If Newton 3.12 and 3.13 did use iterative solvers, then my comment was actually correct.

 

How am I supposed to know that things are changing in 3.14? It's not released yet. And there are no release notes anyway. Besides....

 

 

while leaving the contact to the iterative solver.

 

...you still have an iterative solver for contacts anyway (!). So what I was saying still holds.

 

I don't know why you feel the need to refute absolutely everything I say, no matter how ridiculous it sounds.

 

 

but I understand enough to figure out those two statements contradict each other.

 

Errr. No they don't (?).

 

Your PEEL-master branch does contain the PhysX 3.4 DLLs from PEEL 1.0. But it does not contain the PhysX 3.4 plugin source code (or their PINT binaries). So when you run the EXE you are only presented with PhysX 3.3.

 

As for your video, you don't say how you created it, and the source code is not available AFAIK. But the name of the PhysX 3.4 plugin ("PhysX 3.4 trunk") shows that this is not the one that was released in PEEL 1.1. It is thus very likely the one available in your own PEEL-master branch.

 

Hence, my statements do not contradict each other.

 

 

when you released Peel in GitHub two years later, I downloaded to get the latest but I was not able to use any of the new stuff because Peel comes with a set of compiled libraries that prevent any end users from extending it to make new test

 

What compiled libraries? I don't know what you're talking about.

 

Many users downloaded it, added plugins for their own engine, and created new tests. Dirk Gregorius at Valve did a plugin for his Rubikon physics engine. Havok guys did, for their latest (non public) versions. You yourself sent me new tests that I added to the latest release (like the gyroscopic test).

 

If there is some issue with the latest release preventing people to add their own test, that's the first time I hear about it.

 

 

because that was a dll you put there the same day.

 

I have no idea what you're talking about. What dll?

 

 

It also debunks the statement that you never use Newton because you not understand it, I mean you are saying you looked at it hundreds of time, how could this be?

 

Looking at the PEEL results comparing Newton & PhysX in that branch does not magically teach me how to use your API.

 

 

I do not trust a word coming out from you

 

(shrug) That's unfortunate but I am not going to lose sleep over it. I tried to work with you, I failed, and now I'm sick and tired of this constant BS.

 

(Readers: don't worry, this has been going on since at least 2007, see e.g. http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?p=&f=&t=1334).

 

Decide for yourself who should be trusted. While I'm at it, I'll share with you something I never showed you: what one of your own users on your own forum sent me in private:

 

 

Hi, I Have been reading the latest posts on the PEEL integration issues, and I feel like I should say something publically, but I dare not enrage the Beast any further ;P so I just wanted to let you know you were amazing there! Julio is, in my experience, a bit difficult to deal with in the forums (I don't know him personally). It seems to me he misinterprets things quite easily, and his writing is sometimes 'less than clear', but I had never seen him go so full ballistic over anything... And yet you remained a true gentleman as long as you could (I would have snapped or quit much earlier). Anyway, I'm sorry it ended up like this, but I think you gave it all you could, and hope Julio can improve his attitude in the future (for the sake of all...).

Well done, and cheers!

 

 

I am not the problem.

 

In any case this is going nowhere so I'll stop here.

 

Good luck to your users.

[Newton Dynamics]

What Mr Pierre is doing now is ad hominem attack on my character by bringing topics that has nothing to do with how he misrepresented the competitors in peel, in particular Newton, by both changing other users integrations and by changing the condition of test to favor PhysX and penalize other technologies.

 

He is trying to discredit my character by posting anonymous comments from some person who apparently thinks mr Pierre is amassing and I am a beast difficult to deal with.... and by posting links to a thread of ten year old comments from several thread placed one after another out of context to make me look incoherent and angry when I was simply trying to get an explanation of why his friends did not bother to calibrated the newton engine as it was suggested to them.

 

yes Mr Pierre is correct this goes way back, the question you have to ask is how it is that the

few people who use the newton engine for accuracy do get results when apply proper settings

 

and the so called physics experts who write evaluation tools keep getting wrong results in much simpler tests?

 

 

Before I go on I'd like to briefly explain something most people already know but it is important for background reference.

 

Most large projects use some form of source control manager where programmers, designers and other people work in parallel.

The way people contribute is that they work separately in a local copy of the project that is usually called a Branch.

In these branches, people work for while and when they something ready, they committee it to a common branch where the code is merged for testing.

The code is tested and if is all ok, it is promoted to the final branch

 

It is possible that in the process of merging branches, that some conflict arises that have to be resolved.

there are few way to resolve conflicts.

 

usually the owner is called or some other programmers do the correction.

In general when the correction is done by a person other than the owner,

as a rule of curtesy that programmer put a comment stating he made the correction not the owner.

 

When Nvidea asked me to integrate Newton to Peel, they arranged a branch for me in some source control data bases and I was given a password and a user name.

 

I worked for almost a month integrating newton and I was getting regular feed back from Ratclifh and from mr Pierre himself telling me what worked and what did not work and I complied every time until I got that last Email telling me they were not going to include Newton in Peel and that he personally will make a report in his blog or in my forum, which btw he never did.

from that point on I was cut from source control and I could not make any commit.

 

Mr Pierre Terdiman seem to think that making a contribution means that he decides how the contribution should be written and when something does not go the way he wants he simply change it and make it look as if it was the owner who made the change instead of him.

 

The bottom line is this.

when I made my integration, I played by nvidea rules, I used the tool they provide to me with and I never touched any code that was not mine.

 

if anyone do not believe me I suggest that you download the archive that I provides and also download mr Pierre archive from GitHub and do two things.

1-pick a demo and run it in both demos and explain why in the same demo runs much better in my submitted archive and so different in mr Pierre integration.

2- compare the files related to the newton integration and see if the changes Mr Pierre did are just removing comments.

 

Mr Pierre is also trying to play ignorant and pretending he does not understand why all his excuses are all contradictions.

-he said I used a version of PhysX 3.4 and his own commenet show that not I did no do that I use 3.3 and 3.3.4

-when he could no explain why newton was faster in some cases he said that was because I did not let sleep to be disable, that was simple a repeated lie.

-He assume I was using the same numerial solve as all other engine that was also false.

-He made demos where he applied specific PhysX hacks and when these hack made Physic slower he manipulated the test so that other engine has to run the same hack. he ecen admitted but he do not think this is a dishonest tactic.

-when it is pointed to him that that he fudge some test by changing that inertia matrix only for PhysX but not for other, he do not think this is a cheat al the contrary he thinks Inertia tweaks are part of the bread and butter of game physics. It is legitimate to test these things.

but he forget is doing only for his side.

 

In mr Pierre view a hacks that adversely affect PhysX must be applied to the competitor but when another hack would also benefit the competitor then is ok to suppressed it from the competitor.

He does not see any things dishonest or bias when doing that.

I should point out that these hacks are things a casual user cannot control from the UI, he hard coded these hacks explicitly in the scrip code, so when a casual user set "use inertia scale" for example, that user see physx more stable while having no effect on any of the competitors.

if some one have a name other than a dishonest for these tactics, please tell me, because if that is not a dishonest I do not know what is.

 

They are plenty more of things like that but I think those can make my points.

 

The point here is that.

Mr Pierre can't accept that there is another engine written but a single person with a forum and a simple PC that can even be competitive with his baby written by a team of experts at a cost of over 250 million dollars over ten years.

For then it is an embarrassment that a nobody can even be close and they can't have that.

His solution is to ignored the engine first, when is not possible to keep ignoring, then misrepresent it and when that is not possible then misrepresent the person.

 

This is why you do not see any of the newton results in any of mr Pierre blogs but he is very prolific at showing how physx is better than Bullet.

 

why do you think he is Here now after more than ten years of people asking for comparison?

The reason is that as long as the comparison are anecdotal, they know that they win by popular majority,

this changes if there is a shred of evidence. if there is evidence they know they has to come a show an alternative evidence. And if that fail then they usual trick is attack my command of the language or my character as if that will change the fact that Newton as physic engine is more accurate while competitive speed white with PhysX.

 

He is pretending to be outraged to get an excuse to strip Newton from the tool, but that's just a shell game he is playing.

The reason he does not want Newton there is that he can't justify how a nobody engine can be so close and many time much better than PhysX because that may make some of Physx major users wonder if it is really true that PhysX is the only library in town and that's an affront to PhysX even on his bias implementation.

 

Like I said before.

Open the GitHub so that any developer can be a legitimate contributor and he or she can commit his own

implementation of how his engine is supposed to work.

[Pierre]

You are scary. You seem to have built a complete delusional story that fits your narrative without any regards for facts. I know alternative facts are all the rage these days, but still....

 

Maybe let's try another approach and debunk them one by one, depth-first rather than breadth-first, randomly starting with this one:

 

-he said I used a version of PhysX 3.4 and his own commenet show that not I did no do that I use 3.3 and 3.3.4

 

What I said was:

 

These videos (and Julio's PEEL master branch) unfortunately use an old work-in-progress version of PhysX 3.4. You can grab a more recent build here: https://github.com/Pierre-Terdiman/PEEL

 

So I mention two things: 1) the initial videos posted in this thread, and 2) your PEEL master branch.

 

1) Let's have a look at the video first, for example the first one:

 

a) Do you agree that this video does show PhysX 3.4?

b) Do you agree that the PhysX 3.4 used in this video is not the one released in PEEL in January 2017?

c) Do you agree that there is no PhysX 3.3.4 in this video?

 

2) Let's have a look at your PEEL master branch.

a) Do you agree that it does contain PhysX 3.4 DLLs?

b) Do you agree that they are not the ones released in PEEL in January 2017?

c) Do you agree that there are no PhysX 3.3.4 DLLs in this branch?

 

 

Please answer just "yes" or "no" for each one.

 

I know I should just let it go but it's like a social experiment now. I'd like to see if we can agree on easily provable facts, or if even this is going to be controversial.