Physics stuff

Coordinator
Dec 17, 2007 at 4:25 PM
Check this out Shaw, it'd be a good start for us. I noticed his car's traction seemed based on how much weight was on the tires (possibly even traction). Seemed like he has spring physics for the tires/car. There are many other things in there as well.

http://www.youtube.com/watch?v=HY4p_V6SFhA&feature=related
Dec 17, 2007 at 4:50 PM
I've seen a few posts about this on the XNA forums. Its a port of a light-weight C library.
Dec 17, 2007 at 4:53 PM
Looks good. The cars handling reminds me of the halo warthog :)
Dec 18, 2007 at 5:27 AM
You just want to make sure that we'll be able to support Havoc or PhysX if they go Managed.

There are a few other options on this site as well, such as BulletX, and FarseerPhysics (Though 2d). We just need to make sure that it will be possible to switch what physics engine we are using, but of cause only have one implemented
Coordinator
Dec 18, 2007 at 5:31 AM
I never thought about physics engine portability. I don't know of any engines that can swap physics engines. Is this really desirable? We'll have to abstract the physics code quite a bit, which means we'd lose performance. Performance that I don't think we can afford to lose.
Dec 18, 2007 at 5:41 AM
The best you're going to see from Havok or PhysX is managed wrappers, though Havok is far from free for even non-commercial use. Using a third-party library like BulletX is definitely an option, especially since we're so short on people. I know I joined this project originally as a physics programmer, but as-is I'm not going to be able to start it for months, and my interests in physics are more in the performance aspects anyway. I have no issues staying with the graphics and general engine architecture aspects of the project. It would be a way to get us up and running faster.

I really wouldn't spend much time on physics engine abstraction though. There are just way too many performance bottlenecks in a good physics implementation before you start adding abstraction.
Coordinator
Dec 18, 2007 at 1:09 PM
How limited is BulletX in its alpha state? I'll I've seen is cubes, spheres, and cylinders. We'll need to be able to support full levels, bsps, etc... as well.
Dec 18, 2007 at 3:08 PM
I want to add something here. Ive been lookinga t samples, and they many have the game server handling stuff like physics. How (or if) are we going to support this?
Coordinator
Dec 18, 2007 at 4:17 PM
If we're doing server-client (which I think we already are), then the server is the authority. The server runs its own physics thread, and changes are passed to it. For example, the client tells the server, I've pressed forward, left, right, down, up, left. And the server says, ok, this is where you are now, and five frames later it tell the client again. The client does its own simulation, which most of the time will match, or be close, and when it is doesn't agree with the server, then the server has to update the client. This prevents people from changing something on the client to cheat. The server will treat everyone equally.

I did a report on how server-client should work, but its worth noting that it was only a report, I didn't have to code anything.
Dec 18, 2007 at 4:34 PM
Sorry, I didnt make myself clear. As the game must support host-migration in some form or another, how can we disable and enable the physics processing on the fly? Also Ive coded it so server-client is possible, but peer to peer is just as valid.
Dec 18, 2007 at 5:38 PM
Clients will be doing their own local physics, so when host migration occurs, another client's physics simulation just becomes the authority.
Dec 18, 2007 at 9:43 PM
I think you should try and stick to a pure open source solution where ever possible (the price tag on PhysX is $50K per title!). The best open source XNA library (ive found) seems to be JibLibX "http://www.codeplex.com/JigLibX". I think you could incorperate it, by making your BaseEntity inherit from there PhysicObject class.
Coordinator
Dec 18, 2007 at 9:47 PM
We're certainly open to any managed physics solution, and the more complete it is, the better. I don't think we'll be using a physics engine that costs anything, as this engine itself is free.
Dec 18, 2007 at 10:05 PM


sharpelabs wrote:

I think you should try and stick to a pure open source solution where ever possible (the price tag on PhysX is $50K per title!). The best open source XNA library (ive found) seems to be JibLibX "http://www.codeplex.com/JigLibX". I think you could incorperate it, by making your BaseEntity inherit from there PhysicObject class.


Yeah, we're definitely staying away from pay-by-license solutions. I'd also like to stay away from managed wrappers, so I do want to keep at least providing builds for Xbox, even if we can't support them.

I'll have to take a look at JigLibX. I'm familiar with the original C code base. Originally I wanted to roll my own because there just weren't any fully-managed solutions available that I liked. If JigLibX fits the bill and has a usable license, then its definitely a possibility.

I want to stay away from inheriting the scene graph nodes from physics classes. The scene graph will just contain information about its children, including physics attributes. It should not inherit from a physics actor tree.