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
#422
Vehicles should collide with all physics items in the physx3_advanced branch (physx2/3 & bullet). I fixed that some time ago.
@Chris Calef:
I haven't implemented proper physx3 based vehicles, i will actually be implementing it very soon in Deadly Matter as it's next on the todo list. I can't guarantee it will find it's way back into the physx3_advanced branch here but i will see how i go.
12/28/2014 (5:48 pm)
@Chris DeBoy:Vehicles should collide with all physics items in the physx3_advanced branch (physx2/3 & bullet). I fixed that some time ago.
@Chris Calef:
I haven't implemented proper physx3 based vehicles, i will actually be implementing it very soon in Deadly Matter as it's next on the todo list. I can't guarantee it will find it's way back into the physx3_advanced branch here but i will see how i go.
#423
BTW, on a side tangent, to your knowledge has anybody started hooking up a physics plugin with the Entity/Component build? I'm leaning toward taking a stab at that, but am a complete and absolute n00b in the whole entity/component/interface thing, planning on moving very slowly. ;-)
12/30/2014 (3:22 pm)
Right on, I'm thinking about playing around with it here as well, will be happy to share back anything I get working. Considering physics-izing the cheetah for practice. Great work, thanks for sharing it!BTW, on a side tangent, to your knowledge has anybody started hooking up a physics plugin with the Entity/Component build? I'm leaning toward taking a stab at that, but am a complete and absolute n00b in the whole entity/component/interface thing, planning on moving very slowly. ;-)
#424
01/14/2015 (12:42 am)
Is Anyone Reading This In 2015 ?
#425
01/14/2015 (10:53 am)
Happy New Year!
#426
01/14/2015 (11:31 pm)
Happy new year too ;-). Sorry i don't update this plugin too much these days. The version i have running in DeadlyMatter has so many other additions/changes to the interface it's difficult to maintain this one. Than there is the time factor thing
#427
Got any last minute warnings (or possibly a public version of your to do list?) that you'd want to share with anyone considering pushing the rock uphill a little farther, or basing a finished product off this build?
01/15/2015 (1:48 pm)
Re: time factor, fair enough man, you've certainly done your share! Got any last minute warnings (or possibly a public version of your to do list?) that you'd want to share with anyone considering pushing the rock uphill a little farther, or basing a finished product off this build?
#428
Physics collision filtering and groups. This one i am using in this public version here is very, very basic github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/physics/phys... . What you really want when you add a body(actor) to the scene is the ability through the T3D api to place those bodies into groups than can say collide with or not. You will require a far more advanced collision filter system though github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/physics/phys...
One example is: in DM we have physx body for LOS mesh (not using it exactly like the default LOS stuff in T3D). The LOS is used for AI and nothing more at this stage. Obviously we don't want anything colliding with those BUT we need them for ray casting and sweep tests. Sweep tests is another addition i highly recommend adding, they are useful. The new ray casting/sweep functions i have made available to TorqueScript and have replaced a lot of the containerRayCast stuff with the physics version instead.
Same thing goes for the player hitboxes. I have created physics bodies attached to the bones so they run off the animations providing very accurate shooting and i just ignore the default T3D hitboxes. This allows very accurate detection of head shots, limb shots etc. This works very similar to the ragdolls. Again these bodies we don't want colliding with anything in the scene and are only used for ray casting. Currently in advanced physx plugin, if using any physics plugin the projectile class will use the physics plugin to do it's raycast, the problem here is this raycast is against the player capsule and NOT the default hitboxes T3D uses(they don't live in physics world). github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/projectile.c...
Another area i added was physics constraints. Although DM will never ditch physx i have still made the effort internally to use the proper T3D api. So creating a joint is still like PHYSICSMGR->createJoint(blah blah). I find this way produces nicer code and obviously should your project actually change physics plugins it gives you are fighting chance of implementing it in physics engine X
So much of this stuff would be very difficult to add to the public version because it's really starting to assume want you want to do and what sort of game it is, i don't think this is a good thing. So yeah anyone using this advanced plugin try to think it of it as more of a "base" from which you can use to modify to suit your current project. It's so difficult to come up with a one size fits all solution.
Everything with DM is still very much a WIP but i have found the physics groups one of the more powerful features and really opens up new possibilities to what you can do. It's most likely something i will work on for quite some time getting it perfect.
The two big things on my list are:
Physx 3 vehicles:developer.nvidia.com/sites/default/files/akamai/physx/Docs/Vehicles.html
Apex destruction/cloth.
I have started both but not anywhere near complete, been so busy doing all the other stuff they just haven't been priority number one yet.
Anyways i will do a second post soon outlining a few other problems i have come across and solutions. All in all im very happy i choose physx 3, it is a very nice physics engine and very fast. If you (well anyone) have questions about a specific thing than feel free to ask, i'll try to help.
*Edit:
One other thing i had to do, in the world editor every time you modify the terrain it deletes the physics body and re-creates it. This is not nice for your level designer when using decent size terrain because of the constant pauses. I modified a few scripts so that it won't rebuild the terrian physics body until after you click away from the terrain editor. This way it only does it once. Physx you can actually update the heightmap without destroying it so this would be the ideal way, again just haven't had time to do it.
01/15/2015 (3:52 pm)
Yeah mate definitely:Physics collision filtering and groups. This one i am using in this public version here is very, very basic github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/physics/phys... . What you really want when you add a body(actor) to the scene is the ability through the T3D api to place those bodies into groups than can say collide with or not. You will require a far more advanced collision filter system though github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/physics/phys...
One example is: in DM we have physx body for LOS mesh (not using it exactly like the default LOS stuff in T3D). The LOS is used for AI and nothing more at this stage. Obviously we don't want anything colliding with those BUT we need them for ray casting and sweep tests. Sweep tests is another addition i highly recommend adding, they are useful. The new ray casting/sweep functions i have made available to TorqueScript and have replaced a lot of the containerRayCast stuff with the physics version instead.
Same thing goes for the player hitboxes. I have created physics bodies attached to the bones so they run off the animations providing very accurate shooting and i just ignore the default T3D hitboxes. This allows very accurate detection of head shots, limb shots etc. This works very similar to the ragdolls. Again these bodies we don't want colliding with anything in the scene and are only used for ray casting. Currently in advanced physx plugin, if using any physics plugin the projectile class will use the physics plugin to do it's raycast, the problem here is this raycast is against the player capsule and NOT the default hitboxes T3D uses(they don't live in physics world). github.com/rextimmy/Torque3D/blob/physx3_advanced/Engine/source/T3D/projectile.c...
Another area i added was physics constraints. Although DM will never ditch physx i have still made the effort internally to use the proper T3D api. So creating a joint is still like PHYSICSMGR->createJoint(blah blah). I find this way produces nicer code and obviously should your project actually change physics plugins it gives you are fighting chance of implementing it in physics engine X
So much of this stuff would be very difficult to add to the public version because it's really starting to assume want you want to do and what sort of game it is, i don't think this is a good thing. So yeah anyone using this advanced plugin try to think it of it as more of a "base" from which you can use to modify to suit your current project. It's so difficult to come up with a one size fits all solution.
Everything with DM is still very much a WIP but i have found the physics groups one of the more powerful features and really opens up new possibilities to what you can do. It's most likely something i will work on for quite some time getting it perfect.
The two big things on my list are:
Physx 3 vehicles:developer.nvidia.com/sites/default/files/akamai/physx/Docs/Vehicles.html
Apex destruction/cloth.
I have started both but not anywhere near complete, been so busy doing all the other stuff they just haven't been priority number one yet.
Anyways i will do a second post soon outlining a few other problems i have come across and solutions. All in all im very happy i choose physx 3, it is a very nice physics engine and very fast. If you (well anyone) have questions about a specific thing than feel free to ask, i'll try to help.
*Edit:
One other thing i had to do, in the world editor every time you modify the terrain it deletes the physics body and re-creates it. This is not nice for your level designer when using decent size terrain because of the constant pauses. I modified a few scripts so that it won't rebuild the terrian physics body until after you click away from the terrain editor. This way it only does it once. Physx you can actually update the heightmap without destroying it so this would be the ideal way, again just haven't had time to do it.
#429
01/15/2015 (4:13 pm)
One other problem i still haven't properly solved myself is when using a physics rep with the player, there can sometimes be a slight difference in position of physics bodies between the server/client. When there is, the player will get the jitters because of the difference. This is especially so if you happen to have physics body living client side but not server side.
#430
01/15/2015 (5:48 pm)
Ha, funny you should mention collision filters, that's my current (well, one of my current) blockage points for my Ecstasy Motion port from physx 2.8 to 3.3. Every time I've tried to understand how physx3 does collisions I've gone home with my head hurting (it's a _shader_??) but I'm assuming it's going to make sense one of these days. :-P
#431
So when there is a collision between two pairs it runs it through the filter shader:
En example of what can be done in the filter shader (this is very, very basic):
The different actions are explained here docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/stru...
That filter data has 4 words to use so you can come with quite a few different combinations. I think one of the samples has a good demo on this, which will most likely explain it better. Also i think the vehicle demo would have a good example of filtering too.
The callback modifiers can be handy too
01/15/2015 (6:25 pm)
Yeah i do believe they named it that way purposefully so people think of it like a say a vertex shader. One small piece of code that can run efficiently parallel. I never actually have seen them explain it this way but that is how i always took it to mean. Lol i could be totally wrong but it makes sense when you start to think it was designed to run multi core and on the consoles. So when there is a collision between two pairs it runs it through the filter shader:
En example of what can be done in the filter shader (this is very, very basic):
//suppress collision between these pairs if added to that group in word3 if (filterData0.word3 == Physics_NoCollide && filterData1.word3 == Physics_NoCollide ) return physx::PxFilterFlag::eSUPPRESS; //do more stuff
The different actions are explained here docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/stru...
That filter data has 4 words to use so you can come with quite a few different combinations. I think one of the samples has a good demo on this, which will most likely explain it better. Also i think the vehicle demo would have a good example of filtering too.
The callback modifiers can be handy too
#432
01/15/2015 (6:53 pm)
A little off topic but i think a nicer way in T3D would be to completely split the physics plugin so they are separate libraries from the main engine library. That way the physics plugins are compiled completely separate. Wouldn't be that hard to do actually.
#433
Btw, speaking of off topic, I'm using VS express and it seems to be completely impossible to compile the physx samples due to a reliance on some visual studio pro dependency. Does that sound correct to you? Are you using pro or express? Would sure like to compile the samples... :-p
Oh one more thing, what's the status of joints in this build, then? My apologies but this is actually the first time I've ever really dug into stock Torque physics, since I've been running my own parallel system, but I see there is a MultiActor class in the old physx directory that appears to be for setting up ragdolls or other multi-actor entities. Is that something you were getting to for physx3? Did you use it or make up something else for Deadly Matter?
01/15/2015 (8:09 pm)
Hm, interesting idea. Could see some value in compiling physics interface separately. Also thanks for the link and explanation, so they're not talking about real shaders then. <whew> Btw, speaking of off topic, I'm using VS express and it seems to be completely impossible to compile the physx samples due to a reliance on some visual studio pro dependency. Does that sound correct to you? Are you using pro or express? Would sure like to compile the samples... :-p
Oh one more thing, what's the status of joints in this build, then? My apologies but this is actually the first time I've ever really dug into stock Torque physics, since I've been running my own parallel system, but I see there is a MultiActor class in the old physx directory that appears to be for setting up ragdolls or other multi-actor entities. Is that something you were getting to for physx3? Did you use it or make up something else for Deadly Matter?
#434
Anyway I roughly based my joint system on GMK github.com/logicking/GMK. That has a ragdoll system in it too but i found it kind of lacking but it's certainly a really great starting point though. The T3D physics system has no constraints interface at all :(
I'm using 2012 pro here, i never tried the samples with express. What version of express are you using?
01/16/2015 (1:45 am)
Oh i haven't implemented the MultiActor class in this plugin. It would be a nice addition though, very handy to setup this stuff in max and just export it and it all works.Anyway I roughly based my joint system on GMK github.com/logicking/GMK. That has a ragdoll system in it too but i found it kind of lacking but it's certainly a really great starting point though. The T3D physics system has no constraints interface at all :(
I'm using 2012 pro here, i never tried the samples with express. What version of express are you using?
#435
01/16/2015 (3:30 am)
Is Anyone Online Now 4:49 2015/16
#436
my pc spec.
Cpu : Intel DualCore E5700 3.0 GHZ
VGA : Intel G41 Chipset
RAM : 989 MB(1GB)
OS : Windows 7 Ultimate SP1
01/16/2015 (3:34 am)
OK, Should I need nVidia GPU to use It Or I can Do It One My Pc.my pc spec.
Cpu : Intel DualCore E5700 3.0 GHZ
VGA : Intel G41 Chipset
RAM : 989 MB(1GB)
OS : Windows 7 Ultimate SP1
#437
No you certainly don't need an NVidia GPU to use physx3 ;). The only part of physx3 that can be GPU accelerated is cloth/particles. GPU support is totally disabled in this plugin purposefully.
01/16/2015 (4:10 am)
Lucky i'm in a different time zone...No you certainly don't need an NVidia GPU to use physx3 ;). The only part of physx3 that can be GPU accelerated is cloth/particles. GPU support is totally disabled in this plugin purposefully.
#438
The missing header that threw the error was "atlimage.h", people say that's not included in 2010 express.
I'll give 2012 a shot here.
Bummer about the joints, but I guess that makes my way a little clearer anyway. Be warned, I might be pestering you with a number of questions here in the next few days. I'm finally firing up the Great Refactor that I've been putting off forever. One of my goals is to repackage my physx logic from EM as an addon for the stock torque physics system.
I'm still a total newb with re: to the torque physics system though, trying to figure out where everything important happens. One thing I'm still wondering about is how you handle add/delete of physics objects to and from the scene. In my system I have add/delete lists that I add to in between physics ticks (even though it seems unlikely to create more than one object between ticks) so that during my world step function, I can stop the physics thread, run through the list of everyone who needs to update their position, and then I run through the lists of everyone who needs to be added or deleted, before I start the physics sim again.
From what I can see so far, it looks like the tick function just calls fetchResults and simulate without any other logic. Are we stopping and restarting the sim elsewhere every time we have an add, delete or modify to do, or is there something else entirely going on?
EDIT: Dang, Microsoft, you just get bloatier every time! They used to let you choose C++ only for VS Express, now I'm getting a single option for windows desktop, which installs at 3G, of which only one can be allocated anywhere off of the C drive. Sure, I guess I'll put another 2G onto my SSD drive, thanks for asking... :-p
RE-EDIT: OMFG, well three and a half gigs later, turns out 2012 does exactly the same thing. SamplePlatform-MT fails with "Cannot open include file: 'atlimage.h': No such file or directory". I think it's from some secret sauce library that they only include with the paid version. Why it's mission critical to simple physx samples I have no idea.
01/16/2015 (9:05 am)
Ah, now that you mention it, it's looking like it might just be a 2010 issue, I hadn't thrown 2012 at it yet, and looking again at my thread that pinned it on express, they were specifically talking about 2010 express. The missing header that threw the error was "atlimage.h", people say that's not included in 2010 express.
I'll give 2012 a shot here.
Bummer about the joints, but I guess that makes my way a little clearer anyway. Be warned, I might be pestering you with a number of questions here in the next few days. I'm finally firing up the Great Refactor that I've been putting off forever. One of my goals is to repackage my physx logic from EM as an addon for the stock torque physics system.
I'm still a total newb with re: to the torque physics system though, trying to figure out where everything important happens. One thing I'm still wondering about is how you handle add/delete of physics objects to and from the scene. In my system I have add/delete lists that I add to in between physics ticks (even though it seems unlikely to create more than one object between ticks) so that during my world step function, I can stop the physics thread, run through the list of everyone who needs to update their position, and then I run through the lists of everyone who needs to be added or deleted, before I start the physics sim again.
From what I can see so far, it looks like the tick function just calls fetchResults and simulate without any other logic. Are we stopping and restarting the sim elsewhere every time we have an add, delete or modify to do, or is there something else entirely going on?
EDIT: Dang, Microsoft, you just get bloatier every time! They used to let you choose C++ only for VS Express, now I'm getting a single option for windows desktop, which installs at 3G, of which only one can be allocated anywhere off of the C drive. Sure, I guess I'll put another 2G onto my SSD drive, thanks for asking... :-p
RE-EDIT: OMFG, well three and a half gigs later, turns out 2012 does exactly the same thing. SamplePlatform-MT fails with "Cannot open include file: 'atlimage.h': No such file or directory". I think it's from some secret sauce library that they only include with the paid version. Why it's mission critical to simple physx samples I have no idea.
#439
Some of the API calls in physx 3 are buffered (not all) so you can delete/add/move etc and these will get done by physx after fetchResults is called. I enabled lock/unlock methods for the scene but these are really for thread safety which is not really an issue in T3D because the calls are all coming from one thread anyway, i just wasn't sure how far things would move in the multi threading part so i just added it in(physx internally does run multi threaded if enabled though).
If you are running the checked/debug build you will see warnings in the output window if you doing something it doesn't like during simulation, so just keep an eye out there. If you do notice anything just create your own queue but for the most part i think you should be ok. One thing the editor does that physx doesn't like is with static actors, you are not supposed to move these once added to the scene but obviously you can move em around in the editor, physx will have a sook about this. I just ignore it lol but technically i guess you should remove the static actor from the scene, place it, than add it again. Anyway the output window is very helpful for these cases.
01/16/2015 (3:00 pm)
Oh i never even noticed it uses stuff out of ATL(Active template Library). To the best of my knowledge no express version ships with that? I'm not 100% sure though but i think it's a "full" version of VS only?Some of the API calls in physx 3 are buffered (not all) so you can delete/add/move etc and these will get done by physx after fetchResults is called. I enabled lock/unlock methods for the scene but these are really for thread safety which is not really an issue in T3D because the calls are all coming from one thread anyway, i just wasn't sure how far things would move in the multi threading part so i just added it in(physx internally does run multi threaded if enabled though).
If you are running the checked/debug build you will see warnings in the output window if you doing something it doesn't like during simulation, so just keep an eye out there. If you do notice anything just create your own queue but for the most part i think you should be ok. One thing the editor does that physx doesn't like is with static actors, you are not supposed to move these once added to the scene but obviously you can move em around in the editor, physx will have a sook about this. I just ignore it lol but technically i guess you should remove the static actor from the scene, place it, than add it again. Anyway the output window is very helpful for these cases.
#440
Just out of curiosity, when you do ragdolls in DM, are you simulating them completely on the client side and just telling each client to ragdoll that body right now? I'm assuming any attempt to network all the individual bodypart positions from a central sim would be bandwidth prohibitive, but curious how you're handling it.
01/16/2015 (3:35 pm)
Ah, good to know about that.Just out of curiosity, when you do ragdolls in DM, are you simulating them completely on the client side and just telling each client to ragdoll that body right now? I'm assuming any attempt to network all the individual bodypart positions from a central sim would be bandwidth prohibitive, but curious how you're handling it.
Chris DeBoy