PhysX Fails, Newton Sails

[Newton Dynamics]

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.

[Newton Dynamics]

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.

[Crazycarpet]

When he talks about the incorrect version of PhysX I think he's referring to the change in 3.4 where they completely redid how PhysX handles rigidbody physics.. this was done not long ago and differs from earlier versions of PhysX 3.4 as described here:

 

 

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)

[Newton Dynamics]

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

[Pierre]

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?

[Pierre]

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.

[Newton Dynamics]

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

[Pierre]

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.

[Newton Dynamics]

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

[Pierre]

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?

[Newton Dynamics]

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.

[Pierre]

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.

[Newton Dynamics]

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.

[Pierre]

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!)

[Newton Dynamics]

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.

[Newton Dynamics]

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

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

 

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.

[Newton Dynamics]

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.

[Pierre]

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:

 

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

 

 

 

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

[Pierre]

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.

[Pierre]

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.

[Newton Dynamics]

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:

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

 

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.

[Pierre]

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.

 

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

 

Newton does use a proper cylinder.

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

[Newton Dynamics]

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"

[Pierre]

no, no, no, I was right that PhysX 3.4 use for to make 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"

 

You lost me entirely.

 

I need to sleep.