PhysX 3.x Plugin

#461 Have you noticed some of the NVidia docs/examples are wrong with the swing limits? Very annoying.

#462 Yes, I have, particularly with the linear limits. Hence the lack of support in my build. :-P Haven't taken time to google for solutions yet.

One other thing, I noticed this in my last attempt and took dramatic measures to get around it, but this time I found a less heavy handed approach... there is a name clobbering on a "StringTable" located down in the physx stuff, in include/physxvisualdebuggersdk/PvdObjectModelMetaData.h. This causes a compile error if you ever try to include any physx3 headers in a file that also includes core Torque console/engineAPI headers. The physx one is within the physx namespace, but it must come up as a problem in files that are already using the torque namespace.

Last time I actually went through and changed the name of Torque's stringtable to StringTableT3D throughout the engine, but this time I realized I can dodge the problem if I just make sure to do physx3 stuff in the proper files and don't get sloppy trying to include them where they shouldn't be. Let it be a warning to the uninitiated though, it's a weird and uncomfortable thing getting compile errors way off in the physx headers that nobody would ever touch.

#463 For example in the documentation they have

revolute->setLimit(PxJointAngularLimitPair(-PxPi/4, PxPi/4, 0.1f));

That will actually spit out a warning saying it's invalid and it won't enable the limit. I noticed it can't be a negative value even though the docs say it can. Not sure if this is a bug or just an error in documentation.

Yes that "StringTable" was a pain in the arse too!!. I just managed it by careful header include order

#464 Ah, I did notice something a little funny about my revolute joint, it didn't seem to go both ways equally, and I did use that exact syntax. Weird. At least that compiled, however, unlike any of their linear limit examples...

At least the JointLimitCone ones for the spherical and d6 joints seem to work fine, and the distance joint works fine.

#465 Andrew's Sample Is Not Working, I have Compiled All 16 Project Without Errors.
but I cannot Run "PhysX3-Samples.exe" DirectX error! I have Already Insalled Direct X 9 and my Graphics Card Support Pixel Shader 3.0.

#466 My Custom Engine Build With Full Template And PhysX3.3.
it is Working Without Errors, I have Exported Andrew's Flag.blend to Flag.DAE And Enabled PhysX Cloth, Its Worked. but no colison on Cloth

#467 Right on, congratulations XSpeed! Glad you got it mostly working anyway. The cloth collision is kind of subtle I think, I haven't played with it recently but it seemed like the player would seem to go through the cloth but that it would also have an effect on the cloth, it would be moving after you passed through it.

#468 Personally i removed both the cloth and particles from my own build. Will replace those one day with their apex equivalents but that's not high on the priority list at the moment.

#469 Hey nice work so far chris :)

If i have any further additions i'll post it up to your branch ok ;-)

#470 Thanks, Tim!

#471 Hey Tim, you got any light to shed on a new issue? I just noticed that if I try to play with simType in the datablock script, suddenly I lose all physics on the object. It doesn't matter whether I set it to client only, server only, or server client, as soon as I set a property in the script, it fails. This happens in my earliest copy of your build as well as the one I'm working in now.

On analysis, when I print out the value I'm receiving in unpackUpdate, I find that this function gets called twice. Normally, both times it gets a "2" (client_server) but when I set any value in script, no matter what value, I end up getting a "2" the first time and a "0" the second time.

At this point this is only a curiosity, it isn't slowing me down any, but I thought I'd check with you and see if it used to work but broke at some point? Or if it still works on your end?

(And why would unpackUpdate get called twice, anyway? Isn't that supposed to be a one time thing?)

#472 Do you mean with the PhysicsShape?

#473 Yeah, if I put a "simType=2;" (or 1, or 0) into any PhysicsShapeData datablock, it seems to kill all physics, or at least all client physics, because I can't see anything anymore in the debug render and the objects aren't dynamic anymore.

It could potentially be running on the server, I haven't checked yet, but that would be weird anyway since the only feedback I'm getting is that second call to unpackUpdate(), where it sets it to zero, which would be client only if anything was still working.

As soon as I comment out the simType setting in the script, it goes back to default 2 and everything is fine.

#474 Yeah this is just a generic bug, i didn't create that PhysicsShape stuff, it's default T3D. Yeah you right it doesn't work, does the same happen with physx 2 & bullet?

#475 Haven't checked physx2 or bullet yet. Did make a little progress, sort of, in that I found it seems to have trouble with the "addField( "simType", TYPEID< PhysicsShapeData::SimType >(), ... " in initPersistFields(). I tried changing that to just TypeS32 and it at least successfully reads the number.

I still have it casting to SimType later in unpackUpdate() (which is only getting called once per object, btw; my mistake) so things should be the same from there... but it doesn't exactly work from that point. Setting it to 2 works, but setting it to client only results in sometimes a failure to register object, and sometimes an object but no physics, while setting it to server only gets a crash every time.

#476 Hey chris you have actually discovered a really nasty bug in that PhysicsShape class! I gotta admit i never really looked at this class closely because it all "appeared" to work ok. It's definitely not, will look into fixing this

#477 Ah, okay then, let me know if you figure it out!

Meanwhile I just had another disturbing incident, not sure if this is PhysicsShape related or if it goes all the way up to GameBase, but... have you ever had gamebase objects inexplicably fail to register, and kick out the old "Con::execute - 0 has no namespace: 1" message?

I was messing around last night, possibly later than I should have been coding, but suddenly all my physics shapes just stopped working entirely. I said Oh Dear and started looking back through what I had been working on, but couldn't fix it. Today I took another look at my git diff, etc. convinced I would find some stupid error I made, but found nothing remarkable... then I added a few more printf statements to let me know where exactly it is failing... and with that it started working again. NO DIFFERENCE in code that should have mattered.(!)

This seems very familiar to me, sometimes datablock dependent objects just poop out for no apparent reason then work later, it happens infrequently enough that I haven't ever tracked it down. Wondering now if it's just me or if this sounds familiar to anyone else. Either way I'm hoping Jeff stabilizes his Entity Component build soon, I'd sure like to ditch GameBase and datablocks entirely! I'm storing all my relevant data in sqlite anyway...

#478 OMFG, well this just gets weirder and weirder... I must have a major memory leak somewhere, it's the only thing I can think of that explains my current behavior.

At the time of above comment, I had my simply boxes working again but was getting a new weird behavior with the joints on my articulated figure - it was able to create the joint (apparently) on the client, but on the server with the exact same logic, it gave me undefined values for the positions of the two bodies we're trying to attach the joint to.

Then I again tried to debug with a Con::printf() statement, and once again it just magically started working.

Going back to reevaluate all of my pointer/memory usage...

#479 Well, haven't figured out the weirdities yet, but just to let everyone know there is work progressing even though not ready to commit yet, here's a few pics of what I've been doing...

First, there is a michael4 body with appropriate bodyparts. Title is "almost working" because the hands and forearms are still offset a little, not sure why at this point.


And as of today, they actually bend at the right joint positions, more or less. Unfortunately, as you can see I haven't finished hooking them up properly to drive or be driven by the TSShapeInstance::nodeTransforms yet.


This is an early one where the physics rep was just a flat bounding box on the local YZ plane, but it demonstrated some pretty good rendering performance, I think. (Specific numbers would be irrelevant due to age of my system, but it seems to push polygons better than I'm used to.)


Might have to get pulled off topic for a few days but next project is obviously plugging in the nodeTransforms to create a ragdoll... will report back when functional.

#480 Lookin' sweet Chris, awesome job :)