PhysX 3.x Plugin

#101 We can calculate how many particles that can maximally be in place at one time taking lifetime and emission rate into account.
You can see some ghost code from that in the Px3ParticleEmitter.
Also in ParticleEmitter::allocPrimBuffer you can find this code:

AssertFatal(particleDataBlocks.size() > 0, "Error, no particles found." );
   U32 maxPartLife = particleDataBlocks[0]->lifetimeMS + 
                        particleDataBlocks[0]->lifetimeVarianceMS;
   for (S32 i = 1; i < particleDataBlocks.size(); i++)
   {
     U32 mpl = particleDataBlocks[i]->lifetimeMS + 
                  particleDataBlocks[i]->lifetimeVarianceMS;
     if (mpl > maxPartLife)
       maxPartLife = mpl;
   }

   partListInitSize = maxPartLife / 
                         (ejectionPeriodMS - periodVarianceMS);
   partListInitSize += 8; // add 8 as "fudge factor" to make sure it 
                          // doesn't realloc if it goes over by 1

Would be a good way to determine maxParticles.

#102 I cleaned up the code a little bit and just made another push. Also updated the sample project to include functioning particle demonstration.

I noticed a bug that I'll look into later unless you can find it Lukas. When you exit a level and then join it again there's a crash produced from inside particleemitter.cpp (not px3, the original). I assume something isn't being cleaned up properly when the emitter node is being destroyed.

#103 Just did a small update, cleaned up a bit of the tab spacing to adhere to the T3D coding standard doc. Also fixed up a few small issues causing compile problems on linux/mac.

Over the weekend i'll add better support for linux (sorry don't have access to a mac) with the project generator. I have for testing purposes been using luis dev_linux_opengl to test the plugin on linux.

#104 Also fixed up the trigger shape so it doesn't take part in shape pair intersection tests. Physx3 does have it's own trigger shape flag but i don't feel it's really necessary to use it. I think you would have to derive a few classes from PxSimulationEventCallback and implement the onTrigger function. Current way works just fine, so need great need for it.

#105 Is P3XBody a ragdoll? I see some references to actors in there.

#106 Nope, to quote NVidia themselves:

Quote:
The most important PhysX objects are scenes and actors. A scene is PhysX' representation of the world, and actors are the individual elements of that world

#107 Ah that's a shame, will you be implementing a ragdoll class soon? Or is there one already in there (a soft body?)

#108 Physx 3 has no support for soft bodies at this stage. Here is a quote from an NVidia staff member from their forums:

Quote:
I'm afraid PhysX-3 does not support the soft body feature found in PhysX-2.x. We chose to focus on the clothing use case first. We intend to reintroduce support for soft bodies in the future, but I do not have a delivery date for the feature.

#109 @Andrew and everyone i guess.

I have been thinking a bit lately about the features of this plugin and it finding it's way into the official T3D. As it stands a few files outside the plugin have been modified to accommodate some of the additional features. Personally i see no problem with this as i believe it was done in a way that shouldn't pose a problem to the other plugins but some might not share this view.

What i was thinking of doing was creating two branches physx3_base physx3_extended. physx3_base will only contain the base features required for a T3D physics plugin to operate i.e like bullet plugin, no code changes outside of its own folder.

physx3_extended is basically all the cool extra stuff like cloth,particles and insert <future feature x> and will be what the physx3 branch currently is.

Anyone have any thoughts regarding this?

#110 So is there any way to create a ragdoll? Some other class perhaps?

As for your question I think you should include the extended parts regardless, and then just have a define inside project .conf (that is off by default for stability) that can easily be enabled or disabled.

#111 Ragdoll support could certainly be added, i believe GMK added support for ragdolls. It might be a good starting point to implement it.

I don't know if filling the "core" T3D with a bunch of #ifdef for physx 3 plugin would be accepted into the official repository? Not really keen on it myself.

#112 Timmy, question. How does one enable and/or use CCD?

#113 I really should add a demo for this. PhysicsShape datablock there is a ccdEnabled field. If you are creating a PhysicsBody by any other means there is a PhysicsBody::BF_CCD flag that can be used. It can only be enabled on non static actors.

#114 I must finish off setting up the wiki on github so we can explain all the small things like this that have been added. Maybe a good write up on the cloth and particles too.

#115 Everyone i have updated the original post to show the new branch I created, basically what I have done is create a physx3_basic branch that contains a bare bones physx3 plugin without all the extras and without any modifications to any outside files. If you prefer the extra features just stick with the physx3 branch which is exactly what the plugin was before the basic was added.

#116 Would anyone be kind enough to write a ragdoll physics class for this? I've tried but my programming skills aren't good enough; I think it's an essential feature for any modern game and Torque has never officially supported it.

#117 Just started doing some benchmarks with physx3 vs physx2 vs bullet plugins with the classic box stacking test. I haven't completed the framework fully yet for testing but just from my first few runs dropping 1536 boxes I get the following FPS once everything has settled.

Physx3: 45fps
Physx2: 9fps
Bullet: 9fps

During the falling of the boxes physx2 & physx3 stay above 30fps where as bullet just drops to below 20 than continues to slow down to 9fps and steadies there, where as the physx2 plugin gradually slows down and hovers around 9fps mark. The physx3 steadies and hovers in the mid 40's. Really need the profile data as FPS is not the greatest measurement to use. I wonder if there is a sleeping issue or something with physx2 plugin because watching with the naked eye it's appears as smooth as the physx3 plugin but just bogs down completely as the boxes come to a rest. Anyway need real numbers for this.

This is not very conclusive obviously, over the weekend i'll finish off the scripting side of things so it runs the torque profiler for X number of frames and dump the results and people can see for themselves how much time each physics engine is spending running the simulation. I'll also try and setup a few more test's because obviously there is more to a physics engine than just dropping boxes.

To get the figures above I just compiled each plugin in it's default configuration that is shipped with torque(for physx3 the default repo configuration). Do note that bullet is using a lot lower resolution timing than both the physx plugins so it really has an advantage there.

Both physx2 & bullet just stuttered it's way through the dropping of the boxes and the FPS never recovered where the physx3 plugin just powered through it, quite impressive. Also using the default thread count of 2, i'll have to test with this cranked up a bit higher too. Anyway i'll post better results over the weekend and also the sample project so people can test for themselves.

#118 I just wanted to chime in here, and say thank you for all this!

Up until now, we've always been very intimidated by PhysX and have stayed away from it - the talk of losing all the collisions and vehicles, etc, as well as the general mystery surrounding how to get everything integrated, just seemed like too much.

However, with this thread and the new plugin, I had to try...

And all I can say is WOW!!!!

Bang up job - this went in pretty much without a hitch, although there was a bit of hunting around to find where the changes were made in the regular engine files. But we now have full PhysX in our projects, and I used what I learned in this thread to code up a collision detection system for damage, etc, in script... A bit of a hack, but we have it working the way we like which is great.

Just have a couple of newbie questions though:

1) I really didn't do anything special to my template, except changing over all RigidShapes to PhysicsShapes and adding in the new collision/damage system... I am still using standard Player datablocks, etc, and have not seen any reference to PhysX "actors" in any of the examples - just confused as to the best use of PhysX and whether I should be using another type of datablock for the player?

2) Vehicles... Obviously we can only mount a wheeled vehicle now if it falls on us - when we walk up to the vehicles in a PhysX build, we go straight through. This is a known issue, just wondering what the consensus is on the best vehicle solution? We bought DeepScratch's vehicle kit a while back, but never used it as it was a bit buggy and didn't play well with our custom codebase... But maybe I should try again with a more recent version? Or is there a simple example PhysX-enabled vehicle I can try somewhere?

3) Since we lost all collision on the StaticShape objects, I'm guessing there's no way to do floating platforms using the PathShape resource anymore? Bummer, because that is nice for creating platformer levels and/or dynamic parkour maps... Is there a suggested solution that is PhysX compatible?

4) Have not yet tried the Cloth, as I don't see it in the World Editor. Maybe I missed one of the posts where it explains how to add it to the scene? Wanted to see how it works in our build.

That's it for now... Really appreciate all this work, and am ready to roll up my sleeves and make all our game features work in the new PhysX build we made from this plugin.

Thanks again, everything looks and runs very well, good job!

P

#119 I can handle number 4. Cloth features are built straight into TSStatic objects. So, all you need to do is prepare your model to be used for cloth ( I should do a proper tutorial on this soon ) and then add the object into the world as you normally would (through the Library menu in the world editor) and then you'll see a "clothEnabled" option in the Inspector for the object. Just check that off and when you run the scene you should see your cloth moving. There's a current lack of options for it, I'll be adding a lot more in the near future when I revise it to move it into my game. Things like tension, etc

If you check the samples github you'll find a "blender sources" folder with 2 blender files that show how to setup a mesh to work with cloth. The idea is this:

1) Make an armature consisting of two bones. The second one being a child of the first. First bone will have all free moving cloth vertices weighted to it, second will have all the fixed vertices of the cloth.

2) Make each cloth piece is a separate mesh named Cloth-0, Cloth-1, etc in the same manner as Collision-0, Collision-1, etc

3) Associate the cloth verts with the appropriate bone. You can use the same armature for multiple cloth pieces.

Each piece of cloth needs to have fixed vertices, at least one of them. This is where the cloth will be pinned to. Let me know if you have any issues with it.

#120 Hi Paul,

Question 1) The standard player should use the current physics plugin that is installed.

Question 2) This is an area i have been meaning to fully complete, the default vehicles with torque are currently not compatible with any physics plugin. The Drive kit you mention uses GMK as a base and modified the vehicles to work with it. I must admit at this stage i have no intention of adding support for physx3 to GMK. Physx3 vehicles is definitely an area i'm going to complete, physx3 has pretty decent vehicle support. I have been very busy working on other stuff lately but i'll go back to finishing the vehicle part off soon. It will be physx3 only though.

Question 3) What happens now with collisions and static objects? It should work actually.

Question 4) Andrew answered above.

Completely unrelated but I wrote a benchmark class and performed some benchmarking of bullet,physx2 and physx3. I have only done the classic box dropping at this stage using 400,800 and 1200 boxes, i'll post some nice graphs later today showing the results.