(Video) PhysXActor Derived Player Class
by Henry Todd · 11/16/2007 (3:37 am) · 13 comments
First, thanks to Shannon "ScarWars" Scarvaci for the original PhysX integration resource, currently at version 0.3 and working quite well.
PhysX in TGE Version 0.3 (Work-In-Progress)
Now straight to the video. This is the default test environment that comes with the resource, loaded into starter.fps, but the Player is now a PhysX object. Notice how realistically he pushes the crates, not to mention how he breaks the bridge by jumping too high.
www.youtube.com/watch?v=fEBvRhcVzLg
And here's a simple demo of riding an elevator. I actually just applied upward force to the cubes.. a real elevator wouldn't be free-floating and possible to tip over. I should've jumped to show that the upward force wasn't impacting the player, but you can at least see how his weight slows the cubes down.
www.youtube.com/watch?v=SfwiuGZxUl4
You might notice that when I turned, the cube I was standing on turned with me. The cubes weigh about 20 kg, as opposed to the player's 90, so that's correct.
The resource comes with basic support for Players interacting with PhysXActors, but it's buggy and generally just results in the objects being flung around with excessive force. I decided to try to make Player a child class of PhysXActor instead of ShapeBase; PhysXActor doesn't add anything to ShapeBase except .. well.. a PhysX Actor, and all the support for their interpolation and networking.
It took a bit of hammering to get it working, and a little help from the excellent debug assert code (which ID'd a crash caused by calling addtoscene() in Player and in PhysXActor). I basically nuked every internal use of setPosition/setRenderPosition, since I want the Player to only update based on PhysX. Then I pulled the updatePos function entirely; its collision stuff isn't needed now and it gets in the way of correctly pushing objects. updateMove is then edited to:
1) apply the "acc" vector as force.
2) get mRot.z and mVelocity (which will be used in this function to calculate force) from the transform.
3) Apply move->yaw to angular velocity. Applying torque might sound like it makes more sense, but this creates a laggy control system, and we want it to be exactly the same as the stock Player.
Now the onAdd() function needs to:
1) Not set up the actor (this will be done in the parent).
2) Either set a low center of mass (below the Player's feet) or use the inertia tensor to create the "keep upright" effect of the original Player physics.
And finally in player.h, remove the mActor which was added. There's already one in PhysXActor.
I also removed 4 effectively unused masks from ShapeBase. I'm not sure if you need to do this, but PhysXActor adds 4 of its own, so I'd recommend it. Things like cloak are Tribes-specific and it's unlikely you're using them.
I recommend using a box unless you want your player to fall over constantly or roll down hills (which is honestly pretty fun).
The end result is pretty cool. You can push the physX objects realistically, unlike the original setup, and generally all of Player's functionality is retained. I've even used the inertial tensor to replicate the "keep upright" behavior, which allows you to go back to a capsule for smoother collision with steps and terrain.
Current issues:
1) Run animations work, however the player seems to have some trouble deciding to return to idle. I believe the issue here is the constant application of force to the player keeps it moving slightly, only returning to root after a few seconds of settling. Easiest solution would be increasing the threshold for root animation, but I'm still trying to fix the minor twitching issue.
2) Seems to either fail to place some footprint decals, or places them at an incorrect height on the terrain.
3) The interpolation code for the PhysXActor class isn't as good as Player's. There's a slight bit of snapping that goes on, but this is also true with the boxes and rocks and such. It's very minor in single-player.
4) This will only work as well as the original resource does for multiplayer. I haven't been able to test the PhysX implementation in a real network game, but I assume there could be some lag issues there.
5) Haven't tested this with mounting Players to Vehicles (or any other object). It's probably broken, and will be priority #1 to repair.
Bonus:
1) You can ride elevators, moving platforms, vehicles, it doesn't matter so long as it's a PhysX object with good friction settings! If you set up PhysX cars, you can stand on top of them until a turn or sudden stop throws you off.
2) Can push other players and physics objects realistically. Can be moved by any object that hits you.
PhysX in TGE Version 0.3 (Work-In-Progress)
Now straight to the video. This is the default test environment that comes with the resource, loaded into starter.fps, but the Player is now a PhysX object. Notice how realistically he pushes the crates, not to mention how he breaks the bridge by jumping too high.
www.youtube.com/watch?v=fEBvRhcVzLg
And here's a simple demo of riding an elevator. I actually just applied upward force to the cubes.. a real elevator wouldn't be free-floating and possible to tip over. I should've jumped to show that the upward force wasn't impacting the player, but you can at least see how his weight slows the cubes down.
www.youtube.com/watch?v=SfwiuGZxUl4
You might notice that when I turned, the cube I was standing on turned with me. The cubes weigh about 20 kg, as opposed to the player's 90, so that's correct.
The resource comes with basic support for Players interacting with PhysXActors, but it's buggy and generally just results in the objects being flung around with excessive force. I decided to try to make Player a child class of PhysXActor instead of ShapeBase; PhysXActor doesn't add anything to ShapeBase except .. well.. a PhysX Actor, and all the support for their interpolation and networking.
It took a bit of hammering to get it working, and a little help from the excellent debug assert code (which ID'd a crash caused by calling addtoscene() in Player and in PhysXActor). I basically nuked every internal use of setPosition/setRenderPosition, since I want the Player to only update based on PhysX. Then I pulled the updatePos function entirely; its collision stuff isn't needed now and it gets in the way of correctly pushing objects. updateMove is then edited to:
1) apply the "acc" vector as force.
2) get mRot.z and mVelocity (which will be used in this function to calculate force) from the transform.
3) Apply move->yaw to angular velocity. Applying torque might sound like it makes more sense, but this creates a laggy control system, and we want it to be exactly the same as the stock Player.
Now the onAdd() function needs to:
1) Not set up the actor (this will be done in the parent).
2) Either set a low center of mass (below the Player's feet) or use the inertia tensor to create the "keep upright" effect of the original Player physics.
And finally in player.h, remove the mActor which was added. There's already one in PhysXActor.
I also removed 4 effectively unused masks from ShapeBase. I'm not sure if you need to do this, but PhysXActor adds 4 of its own, so I'd recommend it. Things like cloak are Tribes-specific and it's unlikely you're using them.
I recommend using a box unless you want your player to fall over constantly or roll down hills (which is honestly pretty fun).
The end result is pretty cool. You can push the physX objects realistically, unlike the original setup, and generally all of Player's functionality is retained. I've even used the inertial tensor to replicate the "keep upright" behavior, which allows you to go back to a capsule for smoother collision with steps and terrain.
Current issues:
1) Run animations work, however the player seems to have some trouble deciding to return to idle. I believe the issue here is the constant application of force to the player keeps it moving slightly, only returning to root after a few seconds of settling. Easiest solution would be increasing the threshold for root animation, but I'm still trying to fix the minor twitching issue.
2) Seems to either fail to place some footprint decals, or places them at an incorrect height on the terrain.
3) The interpolation code for the PhysXActor class isn't as good as Player's. There's a slight bit of snapping that goes on, but this is also true with the boxes and rocks and such. It's very minor in single-player.
4) This will only work as well as the original resource does for multiplayer. I haven't been able to test the PhysX implementation in a real network game, but I assume there could be some lag issues there.
5) Haven't tested this with mounting Players to Vehicles (or any other object). It's probably broken, and will be priority #1 to repair.
Bonus:
1) You can ride elevators, moving platforms, vehicles, it doesn't matter so long as it's a PhysX object with good friction settings! If you set up PhysX cars, you can stand on top of them until a turn or sudden stop throws you off.
2) Can push other players and physics objects realistically. Can be moved by any object that hits you.
About the author
#2
I'm sure others would too.
11/16/2007 (5:02 am)
Why not post this as a resource Henry, I'd be interested in looking at the code to see how it performs.I'm sure others would too.
#3
11/16/2007 (5:32 am)
I have a question. Yes I know I could look it up and should. It seems a game wanted me to install PhysX saying it detected hardware (8800GTS). Does that mean the 8800 geometry unit can emulate the P card? 
#4
I highly doubt it. Any game that uses Physx requires the drivers whether you have the card or not. Chances are that the message itself was a mistake.
11/16/2007 (1:02 pm)
@VashnerI highly doubt it. Any game that uses Physx requires the drivers whether you have the card or not. Chances are that the message itself was a mistake.
#5
My plan is to release this very soon. I actually just set it up yesterday, and there are still a couple of things I want to fix, which I'll hopefully get to today. Most importantly, the PhysXActor class crashes the game when one is deleted, even in the original resource, so this also applies to the Player object being removed on death. I also want to fix the minor twitching behavior.. I've minimized it by having the run deceleration stop at very low velocities, allowing the PhysX friction to actually stop the Player, but now mouselook rotation causes the Player to shuffle about about due to the friction it creates vs. the terrain while rotating.
It won't be fixed 100%, as there is still some very minor glitching coming from the PhysXActor interpolation code which will have to wait for version 0.4 of the resource.
Further research has shown that this is actually a problem with the interpolation code from the resource. Objects which aren't updated on time snap to where they should be extremely quickly. Shouldn't client-side physics be handling this?
11/16/2007 (4:04 pm)
Phil:My plan is to release this very soon. I actually just set it up yesterday, and there are still a couple of things I want to fix, which I'll hopefully get to today. Most importantly, the PhysXActor class crashes the game when one is deleted, even in the original resource, so this also applies to the Player object being removed on death. I also want to fix the minor twitching behavior.. I've minimized it by having the run deceleration stop at very low velocities, allowing the PhysX friction to actually stop the Player, but now mouselook rotation causes the Player to shuffle about about due to the friction it creates vs. the terrain while rotating.
It won't be fixed 100%, as there is still some very minor glitching coming from the PhysXActor interpolation code which will have to wait for version 0.4 of the resource.
Quote:Also, it's worth noting that I've now tried this on an actual multiplayer setup, and it's generally way too much data for TGE's default max network settings. This is in the default demo level with the PhysX Player; the number of objects in the scene is too high for the physics to not be kind of laggy.
Further research has shown that this is actually a problem with the interpolation code from the resource. Objects which aren't updated on time snap to where they should be extremely quickly. Shouldn't client-side physics be handling this?
#6
11/16/2007 (4:55 pm)
ragdolls! 
#7
11/16/2007 (6:34 pm)
Awesome - thanks for the extra info too. I'm going to have to try this out.
#8
11/17/2007 (1:13 pm)
Yea thx it does not emulate it. I think the AX install came from Quake Wars ET. 
#9
11/18/2007 (8:50 am)
Very nice! When you plan to release a resource let me know. :)
#10
12/06/2007 (1:15 pm)
very cool... any progress on this yet?
#11
02/01/2008 (7:51 pm)
Sorry for the second post, but are you going to be releasing this code? I tryed emailing you but there was no answer. 
#12
10/20/2008 (8:30 pm)
Just checking even though its been a while to see if you have any plans to share this?
#13
Figured I should put a note on this even though it's several years old. I really have to apologize for posting the videos and blogs and then never getting back to it with some code. I was mostly away from Torque work for a while after I posted this, but that doesn't excuse me never posting the code... especially considering that others certainly could have improved on what I'd thrown together.
For what it's worth, the problem was that it was a mess I hacked up into a copy of TGE 1.5.1 (which was already outdated at the time) without bothering to make any comments or document my process at all. To make things worse this was a highly altered test build I was using to, well, test all kinds of absurd stuff. I'd honestly never expected to accomplish anything when I started working on it.
As far as the system itself, while the PhysX Player looked great in the video it had a serious problem standing still. Basically it tended to kind of bounce around a bit when stationary. Again I think someone with more PhysX knowledge could have solved this.
It was based on the TGE PhysX resource that was available at the time and took advantage of the fact that this resource made a PhysX object which was a child of ShapeBase. Making Player and Vehicle children of that was not all that complicated from that point.
I highly doubt that this code would be in any way useful now, but just in case I'm wrong I'm going to go ahead and post it (assuming I still have it... I think I should). I recall reading that the current T3D PhysX implementation is based on that old resource (though it no longer makes a ShapeBase PhysX object since that's basically bloat for most applications) so who knows... maybe someone will get something out of it.
I'll try to post it sometime this weekend. In the future if I manage to put something like this together I'll make sure it gets to the community regardless of how poorly-coded it is. I'm currently poking around at the T3D physics abstraction layer, hoping I might be able to do something similar to this with its much more stable system, but I can't promise anything as it's really more or a side project.
01/14/2011 (10:57 am)
*reposted from other blog on the same subject*Figured I should put a note on this even though it's several years old. I really have to apologize for posting the videos and blogs and then never getting back to it with some code. I was mostly away from Torque work for a while after I posted this, but that doesn't excuse me never posting the code... especially considering that others certainly could have improved on what I'd thrown together.
For what it's worth, the problem was that it was a mess I hacked up into a copy of TGE 1.5.1 (which was already outdated at the time) without bothering to make any comments or document my process at all. To make things worse this was a highly altered test build I was using to, well, test all kinds of absurd stuff. I'd honestly never expected to accomplish anything when I started working on it.
As far as the system itself, while the PhysX Player looked great in the video it had a serious problem standing still. Basically it tended to kind of bounce around a bit when stationary. Again I think someone with more PhysX knowledge could have solved this.
It was based on the TGE PhysX resource that was available at the time and took advantage of the fact that this resource made a PhysX object which was a child of ShapeBase. Making Player and Vehicle children of that was not all that complicated from that point.
I highly doubt that this code would be in any way useful now, but just in case I'm wrong I'm going to go ahead and post it (assuming I still have it... I think I should). I recall reading that the current T3D PhysX implementation is based on that old resource (though it no longer makes a ShapeBase PhysX object since that's basically bloat for most applications) so who knows... maybe someone will get something out of it.
I'll try to post it sometime this weekend. In the future if I manage to put something like this together I'll make sure it gets to the community regardless of how poorly-coded it is. I'm currently poking around at the T3D physics abstraction layer, hoping I might be able to do something similar to this with its much more stable system, but I can't promise anything as it's really more or a side project.
Torque 3D Owner Henry Garle