PhysX 3.x Plugin

#41 Has that been confirmed for Bullet too? Or just PhysX 2.8 and 3.3? I had a soft theory that it had something to do with putting the physics objects to sleep, then waking them all up when the first bullet is fired, but I don't think that theory would apply if it was still happening in Bullet.

#42 It does it in stock Torque physics. I don't generally use PhysX or Bullet and it happens in every game. Rockets don't seem to do it though I'd have to double check, and it's way more noticeable on puny hardware but it happens.

#43

stateEjectShell[4]               = true;
stateSound[4]                    = RyderFireSound;

These two seem to be the culprits. Primarily ejectShell. I haven't had a chance to look any deeper into it but I'm willing to bet the model for the shell isn't preloaded and that's where the drop comes from. The sound only causes a drop of about ~20 FPS so it's not really a huge issue.

#44 Without running any profiling, it does appear worse though with the physx3 plugin but maybe that's just my imagination.

I'll take a look at this character controller problem too, I did check the physx 2 character controller with PVD and it too hovers above the ground, it certainly appears related to the skinwidth/contact offset.

#45 Yeah i just tried using the cube test level with both bullet,physx 2,physx 3 and the FPS drop is without a shadow of a doubt higher with physx 3 plugin on the first shot. After the first shot it appears identical across all three plugins.

#46 The sound should really probably preload too. I'm surprised the shell model isn't loaded - and it's tiny so it shouldn't be that large of a hit anyway. Weird.

#47 @Richard: Yeah definitely, finally got a few days off so I'll look into this problem.

@Andrew: Good job on the cloth mate, works great over here. I'm going to add support for the CUDA dispatcher too, mainly just for testing purposes and to see exactly what effect it actually has (positive or negative). For others not aware, this will not effect AMD users as it will still run on the cpu dispatcher (this mode is currently used).

#48 Good to hear it's working well. I guess I'll have to go buy an nvidia graphics card now. Wow, did they're marketing plan ever work haha.

I'm taking a few days off from PhysX to get my game up on Greenlight. Should be back at it soon.

#49 Ok i enabled the gpu dispatcher for the plugin and uploaded the changes.

Here is how it works for anyone interested:

PhysX 3.3 only supports gpu acceleration of the cloth and particle systems and only on NVidia hardware (surprise, surprise).

I have enabled gpu acceleration by default for each cloth as this has to be done on a per cloth basis, this can be disabled by setting the datablock field "gpu" to false. AMD user's don't worry as this field is ignored by physx when there is no GPU dispatcher enabled. As for the particle system, i haven't enabled it on that yet as it still needs more work done.

I haven't had a chance to update the sample application binaries with these changes, i will do this tomorrow.

#50 Ok fixed the character controller problem :-) and updated the repo.

Andrew originally added a new field to player.cpp called physicsCollision which was set to false by default(means it doesn't use the physics plugin). Now the character controller is working as per the other two physics plugins i have changed this value back to true by default so it behaves exactly as it does did with the official "GG 3.5 T3D release". I was going to remove this feature completely but i think some people may find it handy/better as it does slightly change the way the player interacts with the scene. So do have a play around with the new physicsCollision field in the player datablock and see which you prefer.

#51 Now that the base stuff appears to be working ok so far I'm going to get busy finishing off the vehicle stuff as I need it done for the project I'm working on.

Hey anyone else using/testing this plugin, do you get a larger FPS drop when firing a projectile for the first time using this plugin compared to torque/bullet/physx2.8 modules?

#52

Quote: as it does slightly change the way the player interacts with the scene.

Yeah, this was the primary reason for adding the option. I also plan on adding a similar option to all objects that are automatically added to the PhysX simulation. I'll follow your lead and default them all to true, but this should give people an easy option for picking and choosing what parts of PhysX enhancement they want without feeling like it's all or nothing.

I haven't had a chance to give it a proper test/evaluation but if you disable those two lines I pointed out above in the player class (stateEjectShell and stateSound) you'll see almost no drop in FPS when you fire the first bullet. Also, if you join the level, fire the gun, exit the level and rejoin it, there's no drop. So, as far as I can tell, it's almost certainly a downfall in the preloading of the sound and/or shell model. I've looked through the code and enabled preloading on the shell (preload = true;) but there's still an FPS drop. I'll have to step through it and profile the two functions and see where it's getting stuck.

#53 I was just wondering how the CCD is in PhysX 3.3. I know in 2.8.4 CCD worked well in Torque (added it in before because I needed fast moving objects and tunneling was happening). Did anybody try out physx 3.3 with CCD?

#54 I'll be honest I haven't touched it. Is there a surefire way to test it? I guess I could just create a wall and then start firing high speed cubes at it until they start going through? From what I'm reading it needs to be enabled on a per-object basis, so I could easily include it with the other physics options I'm adding.

#55 I haven't tried it out yet Jeff, i see no reason why it won't perform as good if not better than in physx 2.8.4. I might do up a demo of it actually as it's a feature some people will require. I'll have a good think about how to implement it nicely as it requires enabling on the scene description,on each rigid body and also the scenes filter shader.

@Andrew:
Yep you are 100% correct about FPS drop, I think i can remove this from the bug list as it ain't related to physx.

#56 K thanks, I was looking at the documentation also, said what you said Andy.

@Timmy or Andy, I'm having unresolved externals in my linker and i followed your instructions on github. I created the port manually.

Here is one of them

px3ParticleSystem.obj : error LNK2019: unresolved external symbol "public: static class physx::PxParticleExt::IndexPool * __cdecl physx::PxParticleExt::createIndexPool(unsigned int)" (?createIndexPool@PxParticleExt@physx@@SAPAVIndexPool@12@I@Z) referenced in function "public: bool __thiscall Px3ParticleSystem::create(unsigned int)" (?create@Px3ParticleSystem@@QAE_NI@Z)

also once i get it working (hopefully....) i'll be testing out CCD.

On a side note, since you guys are doing particles, have you dabbled around with the current particle implementation in stock T3D? It seems somewhat inefficient in some places, and I might be doing some optimizations on that for my game that I'm making. Was wondering if you guys had any tips on where to optimize that if you looked there.

#57 @Jeff:

Oh yeah sorry i need to update the page to reflect the new changes as i was using some nasty #pragma comment lib thing to specify the physx 3 libs but have since removed it because i got the project manager working 100% ok.

So either grab the project manager mentioned on the git hub site (easier) or add the following libs manually to your project:

Release , Debug
PhysX3_x86.lib,PhysX3CHECKED_x86.lib
PhysX3Common_x86.lib,PhysX3CommonCHECKED_x86.lib
PhysX3Extensions.lib,PhysX3ExtensionsCHECKED.lib
PhysX3Cooking_x86.lib,PhysX3CookingCHECKED_x86.lib
PxTask.lib,PxTaskCHECKED.lib
PhysX3CharacterKinematic_x86.lib,PhysX3CharacterKinematicCHECKED_x86.lib
PhysXVisualDebuggerSDK.lib, PhysXVisualDebuggerSDKCHECKED.lib
PhysXProfileSDK.lib, PhysXProfileSDKCHECKED.lib

With debug build feel free to change CHECKED to DEBUG if you prefer but it will still require the CHECKED dll's though.

#58 Got it to work, thanks so much!

To make sure it was simulating i put a printf in the simulation step. Works great, off to continue my project!

I'll be getting my other programmer to test a mac build since 3.3 does have a mac SDK after all. ;)

#59 I would be highly interested in the results of those tests. Let me know if you run into any problems we can fix on our end.

#60 Yep the simulation should be sweet, i tested it against a stop watch when i was developing it and it seemed spot on.

Ok sweet, i knew i put those #ifdef TORQUE_OS_WIN32 in around the cuda stuff for good reason. Do let us know how it goes on the mac :-)