Prev/Next Blog
by date

PhysX FlyingVehicle Prototype (+video)

Name:	Henry Todd
Date Posted:	Dec 12, 2007
Rating:	Not Rated
Public:	YES
Comments:	YES
RSS Feed:	or Subscribe with .
Profile Page:	View profile page for Henry Todd

Blog post

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.

Recent Blog Posts

List:	12/12/07 - PhysX FlyingVehicle Prototype (+video) 11/16/07 - (Video) PhysXActor Derived Player Class

Submit your own resources!

Dave Young (Dec 12, 2007 at 15:03 GMT)

Henry, there seems to be a renewed interest in PhysX lately, if you're willing to share what you've done already there are several of us who can pitch in and work on some of the other details!

Affectworks (Dec 12, 2007 at 15:06 GMT)

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.

Jonathan (Dec 12, 2007 at 18:51 GMT)

can you tell us how you did import PhysX and a hover vehicle ^^

Chris Harpan (Dec 13, 2007 at 03:35 GMT)

I agree with Affectworks, this should be a resource if you have the time Henry. Great job and it looks great so far.

Christopher J. White (Dec 13, 2007 at 12:15 GMT)

this is awsome!!

Henry Todd (Dec 14, 2007 at 05:31 GMT)

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.

Adam Beer (Dec 27, 2007 at 17:23 GMT)

Are you still going to release the player code? I could really use this.

Dave Young (Jan 08, 2008 at 18:50 GMT)

Hey Henry, this came up again today, we'd be happy to help you work out the bugs and details!

Michael Perry (Feb 04, 2008 at 21:38 GMT)

Hey Henry. Just shot an e-mail your way. Still looking forward to your resource *and the following integration of my PhysX goodies =)

Adam Beer (Feb 04, 2008 at 21:45 GMT)

Care to share what those PhysX goodies are? :)

Michael Perry (Feb 04, 2008 at 21:46 GMT)

1. AFX and explosion implementations
2. Ragdoll

I made my own attempt at inheriting Player from PhysXActor...but Torque is giving me a big middle finger right now.
Edited on Feb 04, 2008 21:47 GMT

Adam Beer (Feb 04, 2008 at 21:48 GMT)

I will pay you for that ragdoll implementation. I desperately need it. Whats your price? :D

Michael Perry (Feb 04, 2008 at 21:50 GMT)

My Price =)

Haven't decided on anything yet. Gotta integrate it into Henry's stuff, then polish the dynamic stuff to make the code work with custom rigs and not just Kork

Adam Beer (Feb 04, 2008 at 21:52 GMT)

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.

Michael Perry (Feb 04, 2008 at 22:31 GMT)

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

Ron Nelson (May 08, 2008 at 06:02 GMT)

Just curious if you plan to release this code or sell it?

Ron Nelson (Oct 21, 2008 at 03:30 GMT)

Just checkingback even though its been a while to see if you have any plans to share this?

You must be a member and be logged in to either append comments or rate this resource.