Newton Dynamics

Posted May 5, 2017

here is my second report.

I spent some time last night merging the file differences so that the project compiles and runs.

I have not made any tuning or correction yet, instead I tried to get the same demo that Josh showed at the Benning of these thread. The video is here (I do not know how to make visible)

You will see some glitches because among the stuff ms Pierre omitted are things like

Collision groups and material parameters.

In the demo the newton objects are using the default restitution of 0.6

and only the bodies connected by immediate joints aren't generation contact joints.

Each body is generating a contact joint with every other body that is close enough

that trivial rejection can't decide if is a contact or not, so the more expensive collision routine is called.

This make that newton have to do a lot of house keep work for nothing.

Everyone here with experience using the newton engine knows these setting can and must be control

for a high quality simulation. Later I will adjust those things.

I also made two graphs to show the performance Characteristics of all three engines

Newton 3.14, PhysX 3.4 and Bullet 2.85

you will see that once you remove the burden of Newton having to solve the joints 4 time for no reason,

when he uses his tricks in PhysX and all other engines, the performance do get better but as you see in the video

is not where near the quality of Newton and is marginally slower.

I hope I am using mr Pierre special Physx 3.4 because if I am not, maybe mr Pierre should should my error and put in GitHub the library he would like to see.

1
1

PhysX Fails, Newton Sails

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.

no, no, no, I was right that PhysX 3.4 used for making those videos was not different than 3.4 you have in GitHub,

not that Newton and Physcx are moving target. you are just making that up.

now it turns out the miracle library is not on the archive after all,

but you told people here that I was using a work in progress library I was not suppose to,

that if they only try your version of the Newton Plugin, that they will see Phycx been much better than Newton.

what you did not say was that the reason Phsyx was much better and newton behave worse

was that you changed the test to saddle Newton with 4 + 1 time the same number of joints.

That is what made malfunction and slower.

This is why I say you keep changing the goal post mr Pierre.

If I post the new merge all you have to do is recompile PhysX 3.4 dll with a different serial number and claim that the current one is

"another work in progress"

PhysX Fails, Newton Sails

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

Yes, I did remove the extra shapes and extra joints.

glad you are coming about, we are making progress here

See the cylinder enum, struct and cap bit here:

Yes it is!!!!!!

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

WTF

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

been outraged and saying WTF does not changes the fact that you altered the condition of the test.

if you do not undernat that if you emulate a functionality for one engine, and you go out of your way to replace the support for that functionality on the competitor, is an act that misleading you customers then you have a very different ethics values than any person I know.

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.

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

no it is not, the code does not creates any cylinder simple makes a convex shape.

you can keep saying you are waiting for one until the cow come home as long as you will never accept the once I point to you.

but do not worry I will put a new archive so that people can make comparison and decide for themselves.

I guess that will make you very happy.

PhysX Fails, Newton Sails

I will post my progress report as I make the merge. here is my first report.

I downloaded the current archive form mr Pierre git hub and I am making a file comparison so that I can copy over the new files and merge the one that have conflicts.

I was looking forward to see that PhysX 3.4 work in progress was in fact different that the PhysX 3.4 that was there before when in 2015.

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 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 a screenshot of the part that tells me those files are identical in both archives.

PhysX Fails, Newton Sails

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

to Crazycarpet, you asked for this.

The version in PEEL 1.01 was (I'm fairly sure) a preview version that handled rigid-body differently and as described in the video, it was not a very good design. The PhysX 3.4 in PEEL 1.1 is extremely different from the one in PEEL 1.01.

@NewtonDynamics Any chance you could post your Newton implementation for PEEL or fork PEEL so those who are curious can try out your version, even if it's not on the official branch.

(Using the PhysX version from PEEL 1.1)

This is what I am going to do, I will download the archive that mr Pierre has now in GitHub. and I will go over and make the necessary merge and changes so that project is compatible.

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

When I said, I will merge it, I mean I will correct syntax errors, delete legacies and add newer functions if there are any.

This is very different from changing the code so that it only show what I want, and exclude what I do not want.

This is my prediction.

-as soon as I load the archive, mr Pierre will came back to accused that I used the wrong DLL that I did not retroactively used 3.5 or whatever version he has in his nvidia archive and therefore the test are unfair.

-He will take my archive edict it the same thing he did to the 1.01, post it again and tell people to look at his archive not to mine.

so mark this date and you will see.

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

PhysX Fails, Newton Sails

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.

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.

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

with a tessellated convex but not with the proper shape.

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,

-them in the caps since Physx do not do cylinder I would emulate them with a tessellated

convex hull of any degree.

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

But that is not what you do, 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.

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

you do not see these acts as dishonest intellectually, but I bet you once people know what you are doing that, they see it the same way I do. This is not just one test, they are many more alike mr Pierre.

Even you has to agree that every time you make a mistake, the mistake penalizes the competitor and not PhysX.

PhysX Fails, Newton Sails

do you want a single test?

People can do this. run mr Peirre 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 but 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?

pierre said: Records will show that I did try my best, and that none of this is on me. Ciao.

not you did not, you wrote ridiculous excuses to justify not using a common level field for everyone.

I can see why you run away.

You are counting on people reading me poor command of the English language and and side with you.

I believe that to even the people who dislike me and have a hard time reading my post, that it is clear that of the two of us who is asking for a level field and who is afraid of it.

PhysX Fails, Newton Sails

why should I answer to your errant boy, when he, 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 one of the people who contributed to pall and to your own tests them deny David Gravel from fixing the integration of Newton into Pall?

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

this is what he said:

Dirk Gregorius
Post subject:

Posted: Wed Aug 01, 2007 10:01 am

Joined: Sun Jul 03, 2005 4:06 pm

Posts: 862

Location: Kirkland, WA

Erwin, can you please stop this. Julio is totally abusing Pierre's thread here which I found an interesting contribution. I suggest moving Julio's concerns into another thread.

Julio, with all respect, how can you assume that anybody takes you serious here when you behave like a 12 year old child that was taken away his teddy bear. Maybe you can start a new thread and copy over the relevants posts and I clean up your mess in this thread here.

Regards,

-Dirk

The only answer I have for Dirk Gregory is that he did not has to take me seriously, he and his friend Boing only had to take the Pal Integration David submitted seriously.

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

PhysX Fails, Newton Sails

...was factually correct?

...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".

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

I hate to have to repeat myself for the third time but this is what is factually correct.

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

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

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

There is a name for these tactics, is called changing the Goal Post, which is when the a person keeps changing the standard so that the goal can never be met.

The difference between 3.4 and this magical 3.4 is that you want to show a version of Physx running on GPU versus a versions that does not. When people see that they will be attracted to the new shinny thing and forget everything else.

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

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

Here is what I said to the "neutral people", anyone who doubts the test and believe mr Pierre miraculous PhysX 3.4,

you can simply take the library an copied in the archive that Josh listed on the first page.

you can just run it or compile it, it will work, you will see that with out mr Pierre manipulations, it runs just the same.

as for Mr Pierre.

...

...

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

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

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

PhysX Fails, Newton Sails

@Crazycarpet

If that the case, then they should rename it as they do for other version. what Pierre want to do is for me to retroactively add

code released in 2017 to code he provided in 2015 and I do no believe him. and that's absolutely dishonest.

I do have the latest code with 2017 library and the results are the same once you removed the hacks, Newton

is just better than Phsyx 3.4 and in every other version there was.

The reason Newton perform poor in mr Pierre demo is because he saddles all other engines

with the same joints set from hundreds to thousands of times violating a law of constrained dynamics called Holonomicity.

He does not thinks this is a dishonest tactics but them again he does thinks that hacking inertia value for

PhysX while not doing the same for others is not dishonest either.

For the second question, I will not go again to make new folk or braches to satisfy the curiosity of one person

so that it gets ignored and after few month of work is was all a waste of time.

me proposal is that we commit to the same repository so that every user get to see the whole thing all at once.

the excuses mr Pierre is given that there are other private technologies that he can't publish is just sophistry,

he added what he wanted and everything be put there is public domain already.

if you do believe that there is some miracle weapon version of 3.4 that is thousand time more powerful than 3.4 .

just go to mr pierre archive an check out how for over 10 years he is been making the same kind of claims each time

the had a bug fix or something.

physx 2.8 is tenth of time faster that the predecessor and even one using the predecessor is wrong.

physx 3.0 is tenth of time faster than 2.8 and every one using the 2.8 is wrong.

physx 3.1 is tenth of time faster than 3.0 and every one using the 3.0 is wrong.'

physx 3.3 is tenth of time faster than 3.1 and every one using the 3.1 is wrong.

physx 3.4 is tenth of time faster than 3.3 and every one using the 3.3 is wrong.

now the latest incarnation is that

physx 3.4 is tenth of time faster than 3.4 and even one using the 3.4 is wrong or have some nefarious motivations.

I can assure you that if I spend time doing a new integration, but the time I am done he will come up with

physx 3.5 is tenth of time faster than 3.4 and every one using the 3.4 is wrong.

the only way to terminate that is by we all commit to the same branch. let PhysX shine supreme.

sorry if you do not like my answer but is not funny to be taken for a full many time over.

here is an idea, Josh can integrate physx in this engine, better yet, he can probably get the people at NVidia

to do it for him not only for free, he can even get paid, all nvidia requires is some good promo video.

PhysX Fails, Newton Sails

here is the my proposal.

if you are so unhappy with how my submission makes PhysX look compared to Newton. you can resolve it very easily

you put peel in GitHub, GitHub is a community source control system.

give me commit right so that I can check my own integration of the way I think it should be set up.

I do not mean make a branch, that you merge later, we did that already and you guys simply delete the branch after a while you get what you need.

how about that? that should clear all these confusion and will make the correct version of PhysX 3.4 reign supreme.

PhysX Fails, Newton Sails

again mr Pierre continue conflating the chronology of events. here is the correct chronology.

-early 2013

nvidia asked me to integrate Newton in Peel, the current archive had library PhysX 3.1

when I submit my version he said that I used the wrong version of 3.1 that I should be using 3.3

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

Julio said:

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

mr Pierre replied

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

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

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

-2015

mr Pierre makes Peel public in GitHub, for me to submit my corrections I needed to get the new archive from GitHub which came down with all his libraries that he put there at the time.

I simple made my submit ion and gave it to him.

Few month he releases peel 1.01 and again he changed the new integration these time claiming that that 3.3, 3.3.4 and even 3.4 are old and that I need to use the new stuff he the just released which happen to be 3.4 again.

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

JulioJerez commented on Jun 15 2015

you removed all the callback, the new test I added, and you did even set collision flag.

you did the same thing Adrian Boeing and Dirk Gregorius did whet the wrote PAL to promote Bullet, and refused to accept any correct integration despite many people telling it was not correct

Phyxs is faster than Newton yes, but is that the only thing that count?

Or are you in a bobble that you fell good by making every one else feel worse.

has the decency of being honest.

here is a proper integration

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

for the people reading. In Peel there are many compile libraries for which mr Pierre does not provide source code, they can only be loaded from the Build folder as assets and there is nothing you can do other than delete it from the folder.

Physx 3.4 came from your own archive, you are mentioning this as if I somehow I broke some law.

but Git hub has a history, this can be easily verified from the history, but we do not even have to do that . you said yourself in this thread.

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.

what part of "Because I released a preview of PhysX 3.4 as part of PEEL 1.01, on April 8, 2015. See here:" is confusing to you?

this is what is confusing to me, what was your motivation to put PhysX 3.4 in the archive other than show to show how superior it was to very body else?

had I made the comparison against Physx 3.3, you would be the first here saying that I made the video comparing to an older version of PhysX. Are you saying that PhysX 3.3 is better than 3.4?

To me a fair test consist in comparing apple to apples.

I compared newton 3.13 to PhysX 3.3

but if I want to compared the newer newton 3.14 it would be stupid to compared it to

the old PhysX 3.3

I want to compared to the newest version 3.4

you seem to think that I should retroactively compare it to a version that was not even there.

no mr Pierre it is you who is trying to moody the waters and of the two of us it is clear who is asking for an honest and open source control that is the same for every one.

you are the one asking for integration to be send to you for your evaluation and modifications.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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

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?

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.

PhysX Fails, Newton Sails

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

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.

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.

PhysX Fails, Newton Sails

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.

PhysX Fails, Newton Sails

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

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.

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.

PhysX Fails, Newton Sails

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

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?

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.

PhysX Fails, Newton Sails