PhysX FlyingVehicle Prototype (+video)
by Henry Todd · 12/12/2007 (6:43 am) · 18 comments
Spent the night on this one. Couldn't tear myself away once I got started.
As with my previous Player example, I altered the Vehicle class to inherit from PhysXActor instead of ShapeBase. Once you clear out the extraneous addtoscene/removefromscene calls (this already gets handled in PhysXActor), it'll load without crashing. Comment out a few calls to setPosition inside vehicle.cc, and a FlyingVehicle should now drop into the scene as a PhysXActor. It won't do anything, but it'll be in the scene.
At this point, I went through updateForces and attempted to replace every reference to mRigid with the equivalent call to mActor. During this process, I found out a few fun things about FlyingVehicle physics explaining why they're so strange. UpdateForces produces a bizarre mix of mass-less and with-mass force values, and adds in an extra copy of the gravity force for good measure (probably to counter the hover force, which adds an absurd upward velocity to the object that never stops, no matter the altitude!). Anyway, a bit of clean-up was needed here, but in the end I came up with an equivalent flight model that actually feels a lot more realistic than the default. You can also recreate the stock low-gravity vehicle by enabling the hover force above the set hover height.
This particular vehicle is too fast, turns too slowly, and doesn't have any hover force, but it's fun to fly.
I'd discuss the details more, but I'm legally brain-dead right now. Have a video:
www.youtube.com/watch?v=_Jo6tHPdOiA
Sorry about the YouTube, but Google Video likes to claim videos are live and make you wait another hour to view them. If it ever actually goes live, this one might be slightly better looking:
video.google.com/videoplay?docid=-3855399327398376594&hl=en
It's using an absurdly oversized collision box right now, but you can see that there was a box sitting on top of the vehicle when it started that fell off due to the acceleration. Also, notice how well it handles that high speed impact with the terrain (no glitching).
I'm relying on PhysXActor's interpolation right now, which isn't very good. Vehicle's is much better, and I should replace all the Vehicle interpolation code references to mRigid with mActor. It's solid in single-player, but I believe that Vehicle's warp/interpolation code would be a perfect replacement for the PhysX network interpolation.
The original resources limitations on terrain collision are more obvious with access to this much speed. It misses certain terrain details, especially at larger squaresize and with higher detail, and stops terrain collision outside the central page. I'm not qualified to solve this problem, but I may still have a look at it and see what I can do.
As with my previous Player example, I altered the Vehicle class to inherit from PhysXActor instead of ShapeBase. Once you clear out the extraneous addtoscene/removefromscene calls (this already gets handled in PhysXActor), it'll load without crashing. Comment out a few calls to setPosition inside vehicle.cc, and a FlyingVehicle should now drop into the scene as a PhysXActor. It won't do anything, but it'll be in the scene.
At this point, I went through updateForces and attempted to replace every reference to mRigid with the equivalent call to mActor. During this process, I found out a few fun things about FlyingVehicle physics explaining why they're so strange. UpdateForces produces a bizarre mix of mass-less and with-mass force values, and adds in an extra copy of the gravity force for good measure (probably to counter the hover force, which adds an absurd upward velocity to the object that never stops, no matter the altitude!). Anyway, a bit of clean-up was needed here, but in the end I came up with an equivalent flight model that actually feels a lot more realistic than the default. You can also recreate the stock low-gravity vehicle by enabling the hover force above the set hover height.
This particular vehicle is too fast, turns too slowly, and doesn't have any hover force, but it's fun to fly.
I'd discuss the details more, but I'm legally brain-dead right now. Have a video:
www.youtube.com/watch?v=_Jo6tHPdOiA
Sorry about the YouTube, but Google Video likes to claim videos are live and make you wait another hour to view them. If it ever actually goes live, this one might be slightly better looking:
video.google.com/videoplay?docid=-3855399327398376594&hl=en
It's using an absurdly oversized collision box right now, but you can see that there was a box sitting on top of the vehicle when it started that fell off due to the acceleration. Also, notice how well it handles that high speed impact with the terrain (no glitching).
I'm relying on PhysXActor's interpolation right now, which isn't very good. Vehicle's is much better, and I should replace all the Vehicle interpolation code references to mRigid with mActor. It's solid in single-player, but I believe that Vehicle's warp/interpolation code would be a perfect replacement for the PhysX network interpolation.
The original resources limitations on terrain collision are more obvious with access to this much speed. It misses certain terrain details, especially at larger squaresize and with higher detail, and stops terrain collision outside the central page. I'm not qualified to solve this problem, but I may still have a look at it and see what I can do.
About the author
#2
12/12/2007 (7:06 am)
Terrific work Henry! This should be a resource for sure. It is something that a lot of ppl have wanted in the engine for some time now. 
#4
12/12/2007 (7:35 pm)
I agree with Affectworks, this should be a resource if you have the time Henry. Great job and it looks great so far.
#5
12/13/2007 (4:15 am)
this is awsome!!
#6
At the moment I'm debating how to handle WheeledVehicle. The best solution would be to have the wheels handled as PhysX actors, however there's no reason to actually have them exist in scene and get ghosted; I just want to place them at the location the existing wheel code defines, apply torque to them, and use their interaction with the terrain/whatever surface to create the force. This will get us a much nicer, more realistic wheel force which should remove the "gliding" we often see in the wheeled vehicles. I am concerned about the terrain collision resolution here; in Player, poor terrain resolution results in the Player standing in spots technically a few inches above or below the terrain, which in turn breaks the code that determines if you're on a valid move surface. This same thing would happen with the wheels. Again, this is something that needs to be fixed in the original resource, so I won't be designing around it.
A much quicker solution would be to use the PhysX Actor for the rigid body and just use the existing wheel code. I still need to figure out what the correct conversion of forces is, however; my FlyingVehicle uses completely different force scales than stock as I've removed a lot of the more hacky physics code from updateForces.
Hopefully someone with more experience with the guts of this type of code will be able to spot the base issues with the PhysX resource (maybe having access to some playable PhysX objects will help with debugging? :P), or we'll see a 0.4 release with fixes in the near future. I've got a lot on my todo list, but I'll try to look into these core issues when I have time.
I attempted to apply Vehicle's interpolation code to the PhysX body, but I must not have rigged it up correctly; the resulting interpolation behaved like a Rigid object's bounding box, bouncing back and forth as it moved, instead of the smooth interpolated render position I expected. Running the client-side PhysX world has still been my best solution so far, but it doesn't properly handle the warps created when new server positions are significantly offset from client positions.
That said, it works really well in multiplayer so long as the connection stays decent and you don't expect to ghost 40 physics objects at once. It could be argued that the laggy movement introduced when dozens of PhysXActors are getting position updates is no worse than the same lag introduced when large numbers of Rigid objects get updates. Having 10 or 15 vehicles in a map at once is completely safe as long as everyone's got a broadband connection and you've upped the packet rates/sizes a bit, and even games like the Battlefield series don't expect that many vehicles to exist per map. Expecting to have 64-players all controlling PhysX objects will require some smarter network code.
12/13/2007 (9:31 pm)
Just finished finals today.. I'm going to have an early version the PhysX Player up tonight or tomorrow, and I'll see about the FlyingVehicle after that. I did these mods as brute force, zero-comment code, so I'll have to diff them against a clean TGE152+PhysX03 installation to be sure. TGE's vehicle/prop physics has been a serious stumbling block for a long time, and I'd honestly like to see about getting this code to the point where it could be considered a solid replacement for Rigid. It looks like this can certainly be accomplished -- The terrain collision issues are the most notable bug remaining, though multiplayer interpolation still needs work.At the moment I'm debating how to handle WheeledVehicle. The best solution would be to have the wheels handled as PhysX actors, however there's no reason to actually have them exist in scene and get ghosted; I just want to place them at the location the existing wheel code defines, apply torque to them, and use their interaction with the terrain/whatever surface to create the force. This will get us a much nicer, more realistic wheel force which should remove the "gliding" we often see in the wheeled vehicles. I am concerned about the terrain collision resolution here; in Player, poor terrain resolution results in the Player standing in spots technically a few inches above or below the terrain, which in turn breaks the code that determines if you're on a valid move surface. This same thing would happen with the wheels. Again, this is something that needs to be fixed in the original resource, so I won't be designing around it.
A much quicker solution would be to use the PhysX Actor for the rigid body and just use the existing wheel code. I still need to figure out what the correct conversion of forces is, however; my FlyingVehicle uses completely different force scales than stock as I've removed a lot of the more hacky physics code from updateForces.
Hopefully someone with more experience with the guts of this type of code will be able to spot the base issues with the PhysX resource (maybe having access to some playable PhysX objects will help with debugging? :P), or we'll see a 0.4 release with fixes in the near future. I've got a lot on my todo list, but I'll try to look into these core issues when I have time.
I attempted to apply Vehicle's interpolation code to the PhysX body, but I must not have rigged it up correctly; the resulting interpolation behaved like a Rigid object's bounding box, bouncing back and forth as it moved, instead of the smooth interpolated render position I expected. Running the client-side PhysX world has still been my best solution so far, but it doesn't properly handle the warps created when new server positions are significantly offset from client positions.
That said, it works really well in multiplayer so long as the connection stays decent and you don't expect to ghost 40 physics objects at once. It could be argued that the laggy movement introduced when dozens of PhysXActors are getting position updates is no worse than the same lag introduced when large numbers of Rigid objects get updates. Having 10 or 15 vehicles in a map at once is completely safe as long as everyone's got a broadband connection and you've upped the packet rates/sizes a bit, and even games like the Battlefield series don't expect that many vehicles to exist per map. Expecting to have 64-players all controlling PhysX objects will require some smarter network code.
#7
12/27/2007 (9:23 am)
Are you still going to release the player code? I could really use this.
#8
01/08/2008 (10:50 am)
Hey Henry, this came up again today, we'd be happy to help you work out the bugs and details! 
#9
02/04/2008 (1:38 pm)
Hey Henry. Just shot an e-mail your way. Still looking forward to your resource *and the following integration of my PhysX goodies =)
#10
02/04/2008 (1:45 pm)
Care to share what those PhysX goodies are? :)
#11
2. Ragdoll
I made my own attempt at inheriting Player from PhysXActor...but Torque is giving me a big middle finger right now.
02/04/2008 (1:46 pm)
1. AFX and explosion implementations2. Ragdoll
I made my own attempt at inheriting Player from PhysXActor...but Torque is giving me a big middle finger right now.
#12
02/04/2008 (1:48 pm)
I will pay you for that ragdoll implementation. I desperately need it. Whats your price? :D
#14
02/04/2008 (1:52 pm)
If I had that kind of money, I dont think I would be talking on these forums. If you need help setting up a custom rig I can help you with that.
#15
Something like this:
This way, the ragdoll skeleton can be set up dynamically to work for whatever rig your artist creates for your game. Nifty, huh?
*note*-sample does not reflect end code
02/04/2008 (2:31 pm)
Well, I don't actually need the assets. I have to set up the code to read in a file (sort of like the .cfg files used to export a model to dts from Maya):Something like this:
head = "BIP01 Head" // <--Node, name in model torso = "BIP01 Torso" // <--Node, name in model neck = head,torso 3 // <---Joint, node1,node2, constraint
This way, the ragdoll skeleton can be set up dynamically to work for whatever rig your artist creates for your game. Nifty, huh?
*note*-sample does not reflect end code
#16
05/07/2008 (11:02 pm)
Just curious if you plan to release this code or sell it?
#17
10/20/2008 (8:30 pm)
Just checkingback even though its been a while to see if you have any plans to share this?
#18
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:53 am)
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 Dave Young
Dave Young Games