PhysX 3.x Plugin
by Timmy01 · in Torque 3D Professional · 10/28/2013 (5:11 am) · 500 replies
Update:
If you wish to follow this than please check here github.com/ChrisCalef/Torque3D/tree/physx3_advanced_WIP
If you wish to follow this than please check here github.com/ChrisCalef/Torque3D/tree/physx3_advanced_WIP
About the author
#322
06/16/2014 (10:00 pm)
The problem is the player class is different to all other objects, in physics land this is not like a regular physics object that is affected by gravity and other physics forces. It is affected by gravity but not from the physics engine. I guess it could be modified to do what you want.
#323
Still, makes sense to have it working in physx builds if it's possible, I could see people having fun with that kind of control.
06/16/2014 (10:23 pm)
Yeah I figured it must be something like that... I mean everything else works - the player takes damage from radius explosions and projectiles, etc, he just isn't affected by the forces which is where the real fun lies of course :)Still, makes sense to have it working in physx builds if it's possible, I could see people having fun with that kind of control.
#324
There is a good explanation of the values here docs.unity3d.com/Manual/class-PhysicMaterial.html just swap Bounciness for restitution.
Just remember for the combine mode, you can't yet change this for other physics objects such as PhysicsShape, everything defaults to Average combine but you can at least change it on the terrain end.
06/19/2014 (5:01 am)
Updated testing branch with the terrain per triangle material support. I have showed a video before but here is a new one because i added a friction and restitution combine feature. The restitution value on the sand texture is purposefully exaggerated just to show the difference. There is a good explanation of the values here docs.unity3d.com/Manual/class-PhysicMaterial.html just swap Bounciness for restitution.
Just remember for the combine mode, you can't yet change this for other physics objects such as PhysicsShape, everything defaults to Average combine but you can at least change it on the terrain end.
#325
Another repo update with better onCollision support for PhysicsRigidShape. Let me know what works and what doesn't with it.
Just for anyone else, these last few changes have all been going into the testing branch and not the physx3 branch. It's all become quite a mess i must say lol, code going everywhere. I'll have to clean up the whole thing soon.
06/19/2014 (5:00 pm)
@Paul:Another repo update with better onCollision support for PhysicsRigidShape. Let me know what works and what doesn't with it.
Just for anyone else, these last few changes have all been going into the testing branch and not the physx3 branch. It's all become quite a mess i must say lol, code going everywhere. I'll have to clean up the whole thing soon.
#326
06/19/2014 (5:29 pm)
Woohoo! Thanks, will give it a try tonight and report back the results :)
#327
Tested for various shapes - item, physicsshape, and player all receive hits, the only thing it doesn't seem to detect is collisions with tsstatics. That would be useful as well, so we could have the ball blow up walls and such :)
And was wondering if you had any ideas about the applyImpulse issue, I've been trying all sorts of ways to get the player to respond to explosions, etc but he just doesn't budge lol.
Thanks again!
P
06/19/2014 (9:36 pm)
OK, works great - when the ball bounces off the player, the onCollision call is firing and we can script damage and other events, yay!Tested for various shapes - item, physicsshape, and player all receive hits, the only thing it doesn't seem to detect is collisions with tsstatics. That would be useful as well, so we could have the ball blow up walls and such :)
And was wondering if you had any ideas about the applyImpulse issue, I've been trying all sorts of ways to get the player to respond to explosions, etc but he just doesn't budge lol.
Thanks again!
P
#328
06/19/2014 (9:43 pm)
Ok the tsStatic is easy enough to add. Leave the player one with me and i'll take a look.
#329
I updated to the collision filtering to include the static objects. I am going to leave it how it is for now. If you want to add more, than take a look T3D/physics/rigidPhysicsShape.cpp at the top is static U32 sCollisionFilter. Change the values to whatever you like, the list available is in T3D/objectTypes.h.
I doubt i'll get a chance to look at the player thing for a little while because i am so behind on some other stuff i am working on and i need to get a move along with those. One big one is the vehicles, i really want to get these working. I'll update the thread when i can though, don't forget to have a play around with the new terrain material stuff too, it can help create some interesting effects.
06/20/2014 (1:58 am)
@Paul:I updated to the collision filtering to include the static objects. I am going to leave it how it is for now. If you want to add more, than take a look T3D/physics/rigidPhysicsShape.cpp at the top is static U32 sCollisionFilter. Change the values to whatever you like, the list available is in T3D/objectTypes.h.
I doubt i'll get a chance to look at the player thing for a little while because i am so behind on some other stuff i am working on and i need to get a move along with those. One big one is the vehicles, i really want to get these working. I'll update the thread when i can though, don't forget to have a play around with the new terrain material stuff too, it can help create some interesting effects.
#330
Amusingly, I tried the same scripts with a Bullet executable. I suspect something's a bit funny with the current Bullet implementation, or at least some parameters are determined differently. It ran much more slowly (i.e. just the simulation speed, as if gravity was different) and the boxes seemed to wobble around their bases, even on a flat surface. Ah well, PhysX seems easy enough to set up with.
06/20/2014 (4:19 am)
Finally got the chance to check this out. Awesome work going on! I was inspired to write a brief physics demo based on t3d-bones. It doesn't do anything very impressive - just drops a bunch of cubes in front of a static camera. I also packaged your executables and DLLs up into a t3d-bones release, which comes to only a 7MB download (compared to like 200MB for the current sample project) if anyone wants to get their hands on a very minimal PhysX setup with a built-in example.Amusingly, I tried the same scripts with a Bullet executable. I suspect something's a bit funny with the current Bullet implementation, or at least some parameters are determined differently. It ran much more slowly (i.e. just the simulation speed, as if gravity was different) and the boxes seemed to wobble around their bases, even on a flat surface. Ah well, PhysX seems easy enough to set up with.
#331
Anyone else reading do test out the cloth/particle stuff too and give feedback, Andrew and Lukas did a good job on those too
06/20/2014 (4:55 am)
Nice, thanks Daniel. Yeah honestly physx3 is great and it's super fast. Here are some very brief results i took a few months ago www.garagegames.com/community/forums/viewthread/136369. I know this doesn't even begin to test everything in regards to a physics test, just look online and test for yourself how efficient physx3 really is. The CCD support in physx3 is very good tooAnyone else reading do test out the cloth/particle stuff too and give feedback, Andrew and Lukas did a good job on those too
#332
The physx3 plugin you can change the timing via c++ code (like the other two) or via script physx3SetSimulationTiming(F32 stepTime, U32 maxSteps)
06/20/2014 (5:29 am)
To be fair i should also point out the bullet physics plugin by default runs a simulation of 60hz whereas both physx plugins run at 32hz (which also makes the benchmarks even more telling).The physx3 plugin you can change the timing via c++ code (like the other two) or via script physx3SetSimulationTiming(F32 stepTime, U32 maxSteps)
#333
I also tried the cloth out and although it works great in the sample mission it just chokes in my game... may be something with the fact we have AFX in there or some other incompatibility though, not sure. As soon as the cloth shape is added to the scene the FPS drops to below 5 and it is unplayable until I delete the cloth shape. But it looks great in the sample :)
06/20/2014 (7:15 am)
Tried the new files, but it still doesn't seem to fire the on collision when the ball hits a tsstatic... I can drop several objects in the ball's path, and I have a console echo for each time it registers the on collision - I get echoes when it rolls over a physics shape or an item or the player, which is awesome, but it just bounces off the tsstatic without an echo.I also tried the cloth out and although it works great in the sample mission it just chokes in my game... may be something with the fact we have AFX in there or some other incompatibility though, not sure. As soon as the cloth shape is added to the scene the FPS drops to below 5 and it is unplayable until I delete the cloth shape. But it looks great in the sample :)
#334
So, for some reason only the tsstatics are not being detected with the on collision, although appearance wise the collision is working because the ball bounces off the static without issue. But no on collision is fired for it.
06/20/2014 (9:37 am)
Also just tested collisions against static shape types like breakable glass, and that is working fine too - the boulder collides with it, detects the on collision, and then adds damage and the glass breaks. Pretty cool :)So, for some reason only the tsstatics are not being detected with the on collision, although appearance wise the collision is working because the ball bounces off the static without issue. But no on collision is fired for it.
#335
Good to see the CCD is that good. I was thinking about making a little Superhot-like demo using physics objects for the bullets. Looks like this could handle it fine.
06/20/2014 (4:09 pm)
physx3SetSimulationTiming - does this mean if one were to switch to the bullet plugin one would have to change the scripts? Is this unavoidable? I really appreciated how the basic setup is identical between physics plugins.Good to see the CCD is that good. I was thinking about making a little Superhot-like demo using physics objects for the bullets. Looks like this could handle it fine.
#336
@Paul:
I'll take a look at that static shape issue
06/20/2014 (4:56 pm)
@Daniel: Yeah the other plugins would need support added for the script. I guess i could change it to setPhysicsSimulationTiming or something like this and enable it on all of them.@Paul:
I'll take a look at that static shape issue
#337
06/20/2014 (5:45 pm)
That'd be the idea. If the parameters all mean the same thing to each plugin, then I think we should unify as many functions like this as possible. Also, for example, we should make PhysicsShape available in non-physics builds, but internally it should basically be a RigidShape. I think API uniformity is to be desired. Then if you enable one or the other physics plugin, as much as possible should 'just work'. Obviously some things will have to be different, but let's make sure they really must be.
#338
The static shape doesn't seem to fire the onCollision using the default torque physics either.
@Daniel:
I totally get what you mean about keeping things uniform across the physics engines but physx3 does expose some extra features (like physx2 plugin did) that can't easily be replicated across the other physics engines. For example the vehicle stuff i am working on now, while not impossible to replicate on bullet/physx2 it would take an absolute mountain of work to re-create all the features nvidia have put in place for the vehicle api (with the vehicle stuff, the source code is actually available for that) . Than you have the particles and cloth. Certain features unfortunately are just not going to work easily across the three physics plugins. I guess this is the by-product of having a universal physics plugin system (not saying a universal plugin system is a bad thing).
06/22/2014 (4:48 pm)
@Paul:The static shape doesn't seem to fire the onCollision using the default torque physics either.
@Daniel:
I totally get what you mean about keeping things uniform across the physics engines but physx3 does expose some extra features (like physx2 plugin did) that can't easily be replicated across the other physics engines. For example the vehicle stuff i am working on now, while not impossible to replicate on bullet/physx2 it would take an absolute mountain of work to re-create all the features nvidia have put in place for the vehicle api (with the vehicle stuff, the source code is actually available for that) . Than you have the particles and cloth. Certain features unfortunately are just not going to work easily across the three physics plugins. I guess this is the by-product of having a universal physics plugin system (not saying a universal plugin system is a bad thing).
#339
Basically we're looking to have the new RigidPhysicsShapes be able to act as projectiles of a sort - we have them damaging the player now (thanks again for that), and they can also damage and destroy StaticShapes like breakable glass, but they don't fire the onCollision for TSStatics like the projectile does.
Would that be something in the tsstatic or projectile cpp files we could tweak? Where it sends the onCollision callback for the projectile could we piggyback off that and have it detect physics shapes?
06/22/2014 (8:42 pm)
That's odd about the stock physics not registering it either... Because it fires onCollision callbacks for projectiles that hit TSStatics. We use those to convert some TSStatics to PhysicsShapes on-the-fly when you shoot them.Basically we're looking to have the new RigidPhysicsShapes be able to act as projectiles of a sort - we have them damaging the player now (thanks again for that), and they can also damage and destroy StaticShapes like breakable glass, but they don't fire the onCollision for TSStatics like the projectile does.
Would that be something in the tsstatic or projectile cpp files we could tweak? Where it sends the onCollision callback for the projectile could we piggyback off that and have it detect physics shapes?
#340
06/22/2014 (8:56 pm)
leave it with me and i'll figure it out during the week, it's mostly likely something fairly minor.
Paul Weston
Gambit Realm
The player does not seem to receive impulse or impact energy when being struck by projectiles or by the radius damage from grenades and mines, etc?
If I set the impactForce on a projectile, I can control how far the physics boulder will fly when the bullet hits, that works great. But impactForce does not have any effect on player objects like AI or other players. Ditto with ApplyImpulse - detonating a grenade or proximity mine next to the boulder sends it flying with an onImpulse command in the radiusdamage, but this doesn't happen for the player.
I understand this may not be possible yet for physics shapes hitting the player, until we figure out the oncollision, but I would have thought that if impulse from explosions and bullets works on a physics boulder that it would also work on a player, no?
Unless there's a special way we have to do this that I'm unaware of?
I want to have a mine field where the player is blasted all over the place as he steps on mines, or to have triggers where he is hit by impulse forces that can push him this way and that.