Pierre

Julio I am sorry for the LOLs and WTFs and maybe losing my sh*t a bit.

John tells me you're a nice guy in the real world. Maybe this would all work a lot better if we'd meet face to face. I have nothing against you or Newton.

But seriously man, I don't understand you.

PhysX Fails, Newton Sails

http://www.codercorner.com/blog/wp-content/uploads/2017/05/wtf.png

glad you are coming about, we are making progress here

LOL. I am in the Twilight Zone.

You posted a link to your own forum where I already wrote I would do that. I never denied it. I told you about it before doing it, as we already discussed in this very thread.

you added the enum but then you went to the newton library and deleted the support code and replace with a tessellated convex hull.

LOL. No.

Newton does use a proper cylinder.

PhysX Fails, Newton Sails

I see a file by the name

..\Downloads\PEEL-master\PEEL\Build\PhysX3Cooking_x86_3_4_CL_21578609.dll

and another by the name

../Downloads\PEEL-master\PEEL\Build\PhysX3Gpu_3_4_CL_21578609_x86.dll

maybe Mr Pierre can clarified where is that special library 3.4 that is different than 3.4

so that there is not confusion and he is satisfied, we do not want him to feel like he is been misrepresented.

mean time I will continue.

I am adding an screenshot of the part that tells me those files are identical in both archives.

The 3_4 files are for PhysX 3.4.

The CL_XXXXX indicates the changelist used to build this specific binary. You were entirely right in a previous post that both PhysX and Newton are moving targets, that two binaries with the same name can be separated by years, and this does create issues and ambiguities here and there. I think you actually wrote we should rename the DLLs: that's exactly what we did.

PEEL 1.1 contains a single PhysX 3.4 binary (the state of the trunk at time of release), but at home I support dozens of different "PhysX 3.4" versions, captured at different points in time. This is to track performance regressions, etc. They all have a different changelist number.

I don't know if this answers your question.

PhysX Fails, Newton Sails

to Crazycarpet, you asked for this.

so Mark this date and you will see.

give me a few days to do set that up. I hope Pierre mr has the library he likes there but I know this is just wish full thinking.

You are not off the hook. I request that we go to the bottom of your previous claim before looking at anything new.

In fact here's a deal: if you can actually prove that my changes to your integration code made Newton slower or behave worse, I will take the time it takes to put back that old scene of yours with extra shapes.

PhysX Fails, Newton Sails

https://github.com/Pierre-Terdiman/PEEL/blob/master/PEEL/Physics/Pint.h

it was until you removed the features you did not like. People can play my archive an see the primitive demos. they sure show cylinders and convex hulls.

it was you who removed the cylinders from the archive I gave you, alone with all other shapes and joint types.

Yes, I did remove the extra shapes and extra joints. We went over this N times. I don't have time to maintain a feature that would only be exposed in Newton. This would be best demonstrated in Newton's samples.

In any case this is not what I am asking for. You are now giving me a test that only exists in your version. I am looking for a test that exists in both, and performs or behaves better in your version. You cannot name one because there aren't any. There aren't any because contrary to what you claim, my changes to your integration code did not affect the performance or behavior of Newton.

this is what I, and I think I am not wrong assuming any other honest person, would also do.

-I would add a primitive type cylinder,

OMG did you even look at the code? I already have one!

See the cylinder enum, struct and cap bit here:

-them in the caps since Physx do not do cylinder I would emulate them with a tessellated convex hull of any degree.

I already emulate cylinders with tessellated convexes for PhysX.

-let other engines represent cylinder the best way they can.

This is already what happens!

But that is not what you do

Yes it is!!!!!!

PhysX uses a tessellated convex, Newton uses an implicit shape. This is a penalty FOR PHYSX !!!!!

WTF

you see that If you did that then PhysX will look bad both in quality and performance so you answer is to make every one else carry a penalty.

Ridiculous. The performance penalty is for PhysX.

There are also scenes where Newton looks better than PhysX (e.g. the high mass ratio one) and I certainly didn't remove them or try to hide them. They are still here in both the old and the new archives.

Why do you think people in this thread, who looked at both, chose Newton?

This accusation makes no sense..

Also, these scenes are useful for us. They show where our weaknesses are, and what we should improve. See the InitialPenetration scene for example: it used to explode in PhysX, and we did NOT hide it. But we kept an eye on that, worked out a solution, and now it does not explode anymore.

I do not remove all the tests where PhysX does not "shine".

Now cylinder stacks, tires and anything requiring a round cylinder of high quality has to pay the same high penalty than PhysX does.

This is complete and utter bullsh*t. The cylinder stack uses a cheap implicit shape for Newton, a highly tessellated convex for PhysX. The penalty is for PhysX.

This is not just one test, they are many more alike mr Pierre.

I'm still waiting for you to name a single one.

Then I will upload it next to this version that address 1.01

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

Keep a copy of your old version. Overwriting it would be a convenient way to erase the fact that none of the tests in there actually behaves better than in the new one.

PhysX Fails, Newton Sails

do you want a single test?

People do this. run mr Piree peel and run the cylinder demo.

you will see that not matter what setting you apply, it will always show that PhysX model a cylinders with highly texelated convex mesh and all other engine no with native primitive by with a six sided convex hull.

There are many more samples like that when he explicitly hard code the parameter for PhysX every one else has to run with a different set.

Please run that test and tell me what impression you get from that?

That I call misleading at best, but you Mr Pierre knows well what your purpose was.

We already discussed this test on your forum. You know all the reasons why the cylinder test is like this.

This test did not exist in your PEEL-master branch, so it cannot be an example of how my changes to your integration code made things worse.

Try again.

you will see that not matter what setting you apply, it will always show that PhysX model a cylinders with highly texelated convex mesh and all other engine no with native primitive by with a six sided convex hull.

(This isn't even true anyway, if you click on the checkbox in the UI, everybody uses a highly tessellated convex. Wrong again!)

PhysX Fails, Newton Sails

And answer to why should I answer to you errant boy, you and your palls over the bullet decided to silence me and move all my comment to a different thread out of context.

It woul be the same as talking to you.

Do you contest that Dirk Gegory, was no one of the people who contributed to pall and to your own test and deny David Gravel from integration Newton into Pall.

and them when I try to defend my work Dirk Gegory, Antonio Martini, Eternl Knight, and some other there conspired to remove all my comment to place then out of context on a single thread.

this is what he said:

Oooook I give up guys. Records will show that I did try my best, and that none of this is on me. Ciao.

PhysX Fails, Newton Sails

so basically you listed a bunch stuff to justify not to having a common ground for your own test.

you know that as long as there is ground for confusion, people will side with ndivia by popular majority.

this is a technic used by com and scam artist people a lot.

For example right here in this thread some one was 100% sure that when they run PhysX that they were running in GPU, that's the persuasion power of the magic of confusion.

To this person I said do not feel bad for been taken advantage off, this is what Nvidia has been doing for over 12 years when in reality phyx has never ever run in GPU until 2017and for that they wrote a special hardware and special programing language only they can use.

but There are billions of people out there that are willing to go into a fist fight defending Nvidia PhysX GPU prowess, NVidia will never clarified the issue. It is only on very few occasions when they incidentally get exposed like here now that they see necessary to send an emissary to derail the issue by any mean.

I can assure you that is this was not case with concrete evidence that shows PhysX not as good as they say.

That mr Pierre would not bother to give anyone here the time of day. he is here to muddy the conversation.

mr Pierre keep giving ridicules excuses like.

quote:

b) I am not familiar with GitHub used as a source control tool. If this "commit right" means that anybody can submit anything without a review and the ability for me to accept / reject the changes, this is not going to work ....

c)If this "commit right" allows me to review / accept / reject changes, it is not different from sending me the files directly. ....

d) The "trunk" in GitHub is not the real trunk...

which is surprising to me that a man who has been portraying himself as the smartest person that ever wrote a collision library,

do not understand something as basic as a source control system.

come on mr Pierre, you are smarter than that, you should be able to come up with some better excuse.

your answer is not acceptable

I never ever presented myself as the "smartest person". Please show me a single example of that. You often do random statements like this without ever presenting proofs. (Dirk is still waiting for your answer at the end of this thread: http://newtondynamics.com/forum/viewtopic.php?f=9&t=8836&start=15)

I'm sure I would figure out GitHub if I had the time or motivation to look at it. I just don't have neither of these.

If you keep deflecting the discussion into wild random claims like most of the Internet does, instead of simply pointing out one single test that would prove your claims, I will have to conclude that I called your bluff and that your statements were in fact incorrect.

Please prove me wrong. Please name one test. I am not asking for much. Or anybody else maybe?

PhysX Fails, Newton Sails

factually correct what? No it is not factually correct the you copy the 3.4 version in you archive saying that this was the 3.3 replacement on the third time I did this?

hate to have to repeat myself for the this time. This is what is factually correct.

when I provided the first installment with 3.1, you came back say Phsyx underperformed because Julio used 3.1 instead of 3.3

when I provided the second installment with 3.3, you cam back saying Physx underperformed because Julio used 3.3 instead of 3.4

when I provided the third installment with 3.4, you come back sayin Physx underperform because Julio used 3.4 instead of 3.4

the difference beaten 3.4 and the magical 3.4 is that you want to show a version of Physc running on GPU versus a versions that does.

This is another of the tactics that you and you peers used to appear to polarity.

you some how think that features who are unique to Physx should be shown, but features that are not supporter should be excluded, which is which you insist on that the integration should be send to you so that you can massage the data and the code.

Sigh. Can anybody else explain this to me? Was my previous post unclear?

you keep ignoring my answer, I already told you that if you want to avoid these conflicts, you can simply provide commit right to anyone who wants to integration a physic library to peel instead of every body giving to you a zips files so that you can manipulate pick and chose what to present.

When you have to answer to that, you let me know, I am not going to keep repeating the same over and over anymore.

I already gave you an answer to that. Maybe I can complete it here:

a) This is not the root of the problem. I used GitHub like I could have simply posted PEEL on my blog or something. I did not "manipulate" the files to change the results so this is not the thing we should fix. This whole thing is a red herring.

b) I am not familiar with GitHub used as a source control tool. If this "commit right" means that anybody can submit anything without a review and the ability for me to accept / reject the changes, this is not going to work. People would break things all the time. It already happens at work, I don't want the same sh*t in my personal project. For example they would break the Havok plugins because they didn't bother compiling them. I have about 40 different PINT plugins, nobody's going to compile / test them all before submitting their breaking changes. It takes a lot of work and a lot of efforts to keep everything working for all plugins, even for me.

c) If this "commit right" allows me to review / accept / reject changes, it is not different from sending me the files directly. On the other hand if I take too long to review a change, people will get upset. I don't have a lot of free time and I sometimes don't touch PEEL for a year (as you probably saw yourself, it took forever for your changes to appear in a new PEEL version). If I do a review and find something questionable, I certainly don't want to start never-ending threads about it on GitHub. I don't have time for this overhead.

d) The "trunk" in GitHub is not the real trunk. It misses a bunch of other engines. I would have to constantly fetch changes from GitHub and manually merge them to the master version on my home PC (which is not even connected to the internet). I don't have time for this extra step. It is a lot easier to apply the changes to the master version only, and then upload that to GitHub once every year.

e) You are the only one complaining about this. Other people did their own branch, submitted their changes, and it worked. I am not eager to change anything before we explore other avenues and try to resolve this another way, which I think would be easier.

I also do not understand your point about compiled libraries that you have to delete. I am not sure which libraries you are talking about, or why they are a problem.

In any case, forget this GitHub stuff: it is simply not going to happen.

But I am very eager to go to the bottom of this problem:

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.

I did just that, and I don't see that the tests run "much better" in your archive. Can anybody else reproduce this?

Seriously, let's stop fighting here a bit and let's fix this one. If there is a difference in performance or behavior, I don't see it, and I can guarantee that it does not come from the changes I made (which were just removing unused functions, and extra shapes / joints that PEEL did not support).

So please let's focus on one problematic test and let's look at this in detail.

PhysX Fails, Newton Sails

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.

I would like to go to the bottom of this one next.

With all readers here as neutral witnesses, I will apologize to you if my changes to the Newton plugin integration code you sent created any performance or behavioral regression. And I will then immediately fix the problem in the published PEEL on GitHub.

Deal?

So, first, please tell me which test I should be looking at.

PhysX Fails, Newton Sails

One thing at a time, guys, or we'll never see the end of it.

Physx 3.4 came from your own archive

There. Good. Excellent.

So do we agree that my initial statement, which was:

These videos (and Julio's PEEL master branch) unfortunately use an old work-in-progress version of PhysX 3.4.

...was factually correct?

Do you understand why your initial answer to this statement, which was:

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?

...is thus hard to comprehend?

My initial statement was simple. We do not need to bring a whole "chronology" of past events, or PhysX 3.3.4, into it.

I only wanted to point out that the PhysX 3.4 used in your videos was the trunk from 2 years ago. A lot of CPU optimizations were added since then (which is usual, it happens all the time), but also a full pipeline rewrite for the GPU bodies (which is unusual, we only did that once in the whole lifetime of PhysX 3.x).

It was legitimate to point out that public videos posted in december 2016 showing "PhysX 3.4" are not actually using the PhysX 3.4 official release that we did just a month later.

Anyway I think we are on the same page now: that statement was correct, I was not "confused".

May I move to the next item?

PhysX Fails, Newton Sails

Posted May 3, 2017

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.

PhysX Fails, Newton Sails

Posted May 3, 2017

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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

PhysX Fails, Newton Sails

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

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:

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

it's common knowledge that PhysX is slow when CPU bound

FWIW, most of the "common knowledge" I see online about PhysX.... is wrong

But you are right that none of these engines is "the best". There's performance, memory usage, stability, accuracy, customer support, supported platforms, the API, the documentation, the features, the community, the source code quality, the API stability, and dozens of other aspects, each of them with shades of grey anyway. These engines have pros & cons, strengths & weaknesses, etc. Anybody telling you "mine is the best" is either trying to sell you something, or a fanboy of one particular engine.

PhysX Fails, Newton Sails

PhysX and Bullet do not allow stable stacking anywhere close to what Newton does.

I am not sure what you are referring to here.

You can improve the stacking behavior in most engines by just increasing the number of solver iterations.

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.

In my experience all these engines handle stacking more or less equally well for the same CPU time budget

PhysX Fails, Newton Sails

And how will you argue with the softbody that seems to (and does) work flawlessly in a VERY old version of Bullet, yet in Julio's test with a newer version it somehow fails from a slight tug on the soft-body chain? That's just not correct...

Is the "soft-body chain" you mention the chain made of connected fixed-joint torus? It's not soft-body, it only looks soft because the engines use linear /approximate solvers that didn't converge to the exact solution. It's supposed to be all rigid in theory.

In any case the behavior here will depend a lot on the number of iterations I previously mentioned. It is possible that Julio's video (which might be from 2013 if it's as old as John's email) used a different number of iterations compared to his latest build. Different Bullet versions also use different number of iterations by default (IIRC they moved from 5 to 10), and it will also ultimately depend on the number of iterations I used in the Bullet's setup code, in PEEL.

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.

1

PhysX Fails, Newton Sails