PhysX 3.x Plugin

#61 Hey all, I'm Jeff's partner in crime (just ask him). Mac build is a success with only a few minor tweaks required.
First off: awesome job on the PhysX implementation, works really smooth as far as I can see.

Onto the random things I did to get Mac working:

1. Downloaded PhysX 3.3 and pasted it into Engine/lib/physx/
2. Added all the _CHECKED libraries from Lib/osx32/ to the Xcode project
3. Added the entire Source/PhysXExtensions folder into Xcode for compiling
4. Added _DEBUG and NDEBUG to my preprocessor macros
5. Added ../../../../Engine/lib/physx/include/** and ../../../../Engine/lib/physx/Source/** to my header search paths
6. Did these file modifications:
In SnBinaryDeserialization.cpp and SnSerializationContext.cpp:
Change
#if PX_CHECKED
to
#ifdef PX_CHECKED

Seems to be about it for adding PhysX to the Mac engine. Works like a charm.

Edit to add that I haven't checked out the CUDA stuff yet, but I don't see anything related to it in the download...

#62 Thanks Glenn for the feedback.

The cuda stuff should be irrelevant for the mac as physx doesn't support cuda acceleration on the mac which is strange because nvidia does support cuda on a mac. If you enable any gpu flags on the cloth or particles for example it will just harmlessly fail when no cuda context manager is available.

Anyway glad it's working ok and do report any problems or other findings you may come across.

Oh one last thing(totally off topic), are you using the default OpenGL renderer from torque3d or are you using one of the community efforts?

#63 We are using Luis's openGL port in our engine. I have reported a few bugs dealing with openGL through Glenn's compilation and my compilation on windows in Luis's thread.

We'll report any problems or issues if we come across any. I'll be doing CCD soon...ish as well as I need that asap. (Shouldn't be hard to implement at all, as I already did it with the 2.x port a long time ago)

Again, thanks for doing this. I am still relativly newish to c++, so this saves a ton for me as well as others im sure. I've done TorqueScript for about over 3 years now.

offtopic: do you happen to have a public email address or skype account?

#64 Yeah you can reach me at rextimmy at aim.com

With the CCD don't forget you will need a different filter shader, currently is uses PxDefaultSimulationFilterShader. Anyway NVidia have decent documentation so it shouldn't be too much trouble.

#65 Ok I added in support for CCD which can be easily enabled via a console function physx3EnableCCD(true/false)

Video of CCD Disabled


Now with CCD Enabled


You can clearly see the difference, the fast moving boxes actually collide with CCD enabled. I have to do a little more testing and than I will upload the new code with a bit more information.

#66 Wow, that's awesome. I imagine physx3EnableCCD is just for testing and I assume it turns CCD on for all objects? From what I've read CCD doesn't sound like too much a performance hit, but they must have done it on a per-object basis for a reason so perhaps we should follow suit and make it a per-object flag rather than a global one.

#67 When i did the physX CCD for 2.x, i did it on a per object basis. My suggestion is in the shape datablock or whatever your using, to specify a new field like ccd = true; or something in script and relay that to the engine.

The way you have it set up, does it use it for all actors static and dynamic or just all dynamic?

I think when I did it a while back I only did it on the dynamic actors that I needed, and it didn't tunnel through.

#68 @Andrew:
Yes it's just for testing at the moment as it makes it very quick and easy to globally turn it off/on for testing. You can just exit a level,disable/enable it and re launch the level.

@Jeff:
With physx 3.3 the CCD flag is only for PxRigidBody, it has to be capable of having a velocity but having said that as long as you use the PxPairFlag::eCCD_LINEAR with the pair flag in the filter collision shader it will collide with static objects (as seen in the video).

Yep it will have to be done like Jeff mentions and add a new value to PhysicsShape to enable/disable ccd per object (disabled by default) and leave CCD globally enabled (scene level) which should have very little to no impact on performance. The only problem in adding a field to PhysicsShape is both the bullet and physx2 plugin don't have ccd support added in yet, so having a ccd field on PhysicsShape could be confusing for anyone using those plugins. I guess these other two plugins could have it added as both obviously support ccd.

#69 bullet CCD is pretty crappy. last time i used it in Torque3D, my sphere hit the ground with a HUGE velocity and had no restitution force applied, even with the materials having restitution scalar. I wanted to use bullet instead of the physx 2 back then, but when i saw that, I needed restitution forces on spheres so I went with PhysX.

When i used it, bullet's ccd "world" stated it was incomplete and you should use discrete "world" instead so maybe thats why? I don't know if they have fixed the issues since or not.

I also have a suggestion for you since your doing physics related stuff: ignore the physics shape class and create a new class on ShapeBase, as shapebase gets a ton more methods than gamebase. Why they used gamebase is beyond me as shapebase has a ton more stuff.

#70 Yeah i guess it really depends on what you want to do with your physics object, as ShapeBase is a massive class and with that comes massive bloating(aka datablock network spamming lol) if you don't need it's features I recommend not using it at all. That one is really situational though.

I have also added a new console function called physx3SetSimulationTiming( F32 stepTime, U32 maxSteps ) so you can via script change the timing to better suit your own project without needed to recompile.

The CCD stuff is working sweet, what i have done is permanently turn it on at a scene level but disabled CCD by default on a per object level. I have added a new flag to the PhysicsBody class called BF_CCD and i have added a new member to the PhysicsShape data block called ccd (disabled by default). So the other physics plugins that don't have ccd will still function perfectly as they did before it's just enabling ccd per object for those plugins will do nothing.

I'll upload it all soon.

#71 awesome timmy! Thanks again for your hard work. I might not download <that> part that deals with the physicsshape as i am not making use of that in my game.

Srsly this is one of the reasons why i came back to torque when i saw this and opengl. i was working in unity but man did i miss my torque c:

#72 ok updated the repo with these changes, I haven't had a chance to update the samples yet.

Yep I like Torque3D, it is in desperate need of a bit of loving but generally its nice to work with.

Hopefully for Bullet's sake version 3.0 fixes up a few problems for them because it is rather lagging behind PhysX 3.3 and i'm definitely not an NVidia fan boi, it's just currently (for my own uses) PhysX 3.3 is a far better solution for me.

#73 I'm going to take a small little break from the physics and go have a play around with Luis's OpenGL stuff as this interests me greatly and hopefully i can contribute something towards it :-)

#74 While Timmy has been on break, I've been doing stuff related to the plugin.

I revamped the material system that maps to textures, to accept their own static/dynamic friction and restitution values, and now triangle meshes now have material-based friction! So say on your triangle mesh you had an ice patch, well now its slick. No need to make it a separate object!

If there is any interest in this, I will happily submit it to this port.

#75 That sounds really cool. Is the code available on github? I'd love to try it out and review the changes. Sounds like a great addition to the plugin.

#76 Yeah that would be a nice addition. I really need to clean up the repository as the PhysX3 plugin should be sitting in it's own branch and not in the development one. I'll update the original post when i get around to this, in the mean time feel free to send a pull request through with your changes so we can take a look ;-)

@Andrew: Congrats on the steering committee thing

#77 I would but unfortunatly I found a bad bug, some of the materials are actually not setting to the right physX material. I'm afraid I'm going to have to do a little debugging. Once i get it working completely (thought it was, spoke too soon) I'll have to send a pull request.

#78 Yeah no dramas Jeff, take your time.

#79 Just a notice for everyone i have changed the branch name for the plugin, it is now in the physx3 branch github.com/rextimmy/Torque3D/tree/physx3, i have updated to original post to reflect this. I will be resetting the development branch back to where the official T3D is currently at.

#80 @Andrew and @Lukas:

I think i accidentally wiped that last pull request from Lukas when merging stuff over to the physx3 branch. I think andrew merged in one but there was one remaining??? If so sorry Lukas, could you resend it to the physx3 branch.