by date
Plan for Clark Fagot
Plan for Clark Fagot
| Name: | Clark Fagot |  |
|---|---|---|
| Date Posted: | Apr 21, 2005 | |
| Rating: |  4.8 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Clark Fagot |
Blog post
Simple collider, component system, networked collision, networked physics
The last few months I've been working on a simple collision/physics system for dRacer. The basic goals of the system are that it should allow a few different simple collision image types (in the end, box and sphere), use poly soup collisions, and be network friendly. The reason for choosing box and sphere collisions only, rather than something more general like arbitrary convexes using gjk is that we only need box sphere, and we can do faster and more accurate collisions if we customize. The reason for wanting poly soup collisions, other than that they are much easier to work with (e.g. terrain convexes are, in the worst case, simply a single poly with some extra gunk added), is that they can be done fast, efficiently, and are more easily implemented than general collision systems like gjk.
You might wonder why I'd be inventing a whole new physics solution. Aren't there workable solutions out there, you might ask? Here is the landscape as I saw it:
Existing physics solutions:
1) Modified ThinkTanks collision/physics previously used in dRacer. Poly soup collisions but incomplete routines for detecting collision positions. Written with assumption that car would be on the track and we'd only be colliding with other cars and the track walls. Assumed box collisions for collisions with static objects and sphere collisions for dynamic collisions (ThinkTanks purposely used spherical body aspect to make this work).
2) Torque collision/physcis. More general convex collisions using gjk. Physics system refined and works over the net. A number of apparent issues - objects have a tendancy to get stuck, even when colliding against simple geometry like terrain (simple is in the eye of the beholder, but terrain is simple from a physics sim perspective because changes in the surface curvature are much more gradual than, say, a wall with 90 degree turns). CPU load is higher than one can tolerate for a fast moving racing game. Stacked rigid objects result in odd warping behavior. Unclear if this is due to cpu load, network bandwidth, or numerical imprecision.
3) Use ODE. ODE can handle a lot of items stacked and piled on top of each other. Problem is that it isn't networked. GG Josh has spent a fair amount of time trying to get ODE play nice over the net, and he has not had success. The big problem is that it uses a global step and this doesn't allow the network backstepping that Torque does (essentially, reseting the world to an earlier state and resuming, but only on those items which were just updated).
I wasn't really interested in tracking down all the issues to get #2 or #3 working up to the level we needed. So I started from #1. I know that sounds like more work, but what I was looking to build was a more reliable but smaller system, and I find that it is often easier to build up to this than building down from a more complex but flawed system.
Here is a video of the results (remember, this is not client only, this is network friendly):
Simple collider video - MPeg 1
Simple collider video - MPeg 2
These are the same video, just different encodings, so be easy on our server and only download one.
I also want to note that this is a component in the component system. So any object can be based off it. E.g., the race car uses the same Com3DMover component that the blocks and the sphere use. The collision image for the car is a box collider, which is the same as the blocks you see being moved around in the video.
This is nearing the end of this system as it needs to be developed for dRacer. But after dRacer I will continue development of it (and some day you should see it in some version of Torque as one of the key components in the component system). Down the line, here are some tasks I see still needing to be done:
- rest condition
Ok, so this I'll do for dRacer. Right now there is no rest condition. Because of this, the cpu load when things are stacked or are just sitting around is much higher than it needs to be. A rest condition is the cure for this ill (but notice in the video that there is no jitter even though I'm not detecting a rest condition).
- network smoothing
This I will also do for dRacer. You might notice that from time to time the update isn't entirely smooth. This is because it is networked, and the client is updated with very poor precision in order to reduce bandwidth. I was VERY surprised with how WELL the physics actually worked over the net. I expected that mis-prediction and jittery updating would be the rule, and to get around this we would have to avoid unpredictable situations (like stacks of blocks being toppled). But that wasn't the case. To get rid of the bit of jitter that is seen, I plan on adding a smooth to the render transform (say, about 250 millisecond smooth). This will be part of the mover component, so it's a feature that can be turned on and off on any object in the game. That's one of the huge benefits of the component system. Deep features like this can be shared amongst all objects very easily. Imagine implementing a similar feature on the vehicle class and now wanting to use it on the player.
- swept collisions
Currently I simply do a binary search to find collision location. This is not the fastest solution, but keeping in the spirit of the current work it is simple and fast enough for dRacer. Eventually, some swept collision checking will need to be done instead.
- more collision images
Sphere and box do the trick for now. I'd like to eventually add ellipsoid (scaled spheres), capsules (swept spheres), and tubes.
- convexes and gjk
As mentioned above I eschewed doing general convex collision because it simply isn't needed for practically any game. But for a sophisticated game engine like Torque it is nice to have the option for special cases. So eventually I'd like to add gjk to the current system. The way the components are set up now, it should be fairly straight-forward to add new collision types, including convex collisions using gjk. The main constraint is that each collision image has a priority, so higher priority images need to know about and deal with lower priority images. So one can add new collision types without re-writing the old collision types. So, in theory, one could add the current Torque gjk solution to the component system as a special case for when a more complex collision image is needed.
- unions and intersections of images
This is getting pretty far afield from where I see the system going in the near term, but there is no reason one couldn't add unions and intersections of collision images to allow one to build up to much more complex images, not unlike what is done now with Torque convex collision images.
- neighbor optimizations
One of the inefficiencies of the current system (shared by the standard Torque collision system) is that nearby objects often duplicate effort. For example, the pile of balls on the terrain in the video are all grabbing polys from the terrain. I'd like to have groups of objects enter a collision step together, sharing some of the work. This could also be useful for determining update order much like what is called a "shock step".
Recent Blog Posts
| List: | 06/14/05 - Plan for Clark Fagot 04/21/05 - Plan for Clark Fagot 02/06/05 - Plan for Clark Fagot 04/14/04 - Plan for Clark Fagot 10/22/03 - Plan for Clark Fagot 01/06/03 - Plan for Clark Fagot |
|---|
Submit your own resources!| Josh Williams (Apr 21, 2005 at 22:59 GMT) |
Nice write-up Clark. :)
| Brett Fattori (Apr 22, 2005 at 00:05 GMT) |
Ok, I'm patting us on the back now... I should quit.
- Brett
| SundayMalice (Apr 22, 2005 at 01:03 GMT) |
I've been working on TGE-ODE integration for a while now, but prior to starting this project, I thought about making collision/physics enhancements to TGE as you have done. Your work is outstanding:)
I think mixing the box and sphere collision to remaining gjk/convex hulls shouldn't be too difficult. I may have a better solution on how to handle tri to tri collision in the ConvexFeature::collide() function.
Anyway, it's always good to see your enhancements to the engine. Keep up the good work:)
| David Blake (Apr 22, 2005 at 01:57 GMT) Resource Rating: 5 |
This is about real physics that move beyond the wow factor and into the gameplay factor. Driving and fighting simulations were about the only things that actually utilized physics in gameplay terms that I can think of other than Half-Life 2.
Great job!
| Jeremy Alessi (Apr 22, 2005 at 03:28 GMT) |
| Jay Moore (Apr 22, 2005 at 03:56 GMT) Resource Rating: 5 |
Quote:
This is about real physics that move beyond the wow factor and into the gameplay factor. Driving and fighting simulations were about the only things that actually utilized physics in gameplay terms that I can think of other than Half-Life 2.
Are you saying you don't see physics effecting gameplay in anything but fighting & racing??
Have you played the RocketBowl demo? This is ODE in a shipping game (not networked), but I smile every time I play watching the pin action based on the physics model they used. All that GISH is, it owes to physics in a side scroller. Did you play Chain Reaction? I agree with you on ragdoll that it rarely lives upto the fun of its buzz, but I think well integrated networked physics in Torque will be important in lots of gameplay.
Edited on Apr 22, 2005 03:57 GMT
| Ben Garney (Apr 22, 2005 at 06:56 GMT) |
Any game with a lot of dynamic situations is going to have physics in it - FPS, racer, platformer, even puzzle games (Incredible Machine, anyone? ;).
| Josh Moore (Apr 22, 2005 at 08:39 GMT) |
| Michael Cozzolino (Apr 22, 2005 at 11:15 GMT) Resource Rating: 5 |
| Joshua Dallman (Apr 22, 2005 at 14:16 GMT) |
| David Blake (Apr 22, 2005 at 14:27 GMT) Resource Rating: 5 |
I didn't clarify, but I was thinking more on the commercial side since there is less freedom to work with gameplay than in the indie side, while there's less budget to bang out Quake IV on the indie side.
@Ben
Yeah. I realize that. It's almost the same method as the Ragdoll pack, but more complex. Extremely bad example on my part. Everyone should be used to that by now, though!
| Clark Fagot (Apr 22, 2005 at 21:36 GMT) |
@Jay - oh sure, start a flame war in my plan. Do I go into your office to fart? :)
Seriously though. I think ODE is great. I used to have a real bad image of all these physics packages out there. I think it partly dates back to looking at a demo of -- I think -- math engine back in 99 or so. It was your typical blocks demo but it had all these frame rate jitters and whatnot when things would stack. It was the type of demo that made you wonder why they didn't just make a video. It wasn't the type of thing one could actually use in a game. I've also been dissapointed by just about every physics engine's vehicles physics. I remember playing a demo at GDC a number of years back of the Havoc vehicles. The thing drove like a boat. Every ODE vehicle simulator I've tried has similar issues.
But -- getting back to the ODE is great theme -- I have recently seen some of the ODE demos and they are far past the Math Engine issues. I think it (or packages like it) are the future. I just don't think the future is quite here yet. I love the way the Large Animal guys have used ODE in RocketBowl. That's beyond what you could expect to get with my system (unless you wanted boxy pins :).
But the uses of ODE are limited right now. You don't get networking, and it does have a lot of cruft that isn't necessary for most games. If you simply want to make a networked platformer where your character can run around, throw crates and push boulders -- hey I got your system right here. The simple collider I've created covers about 80% of the games I'd want to make, so I obviously feel it ought to be a base component for an engine like Torque.
| Phil Carlisle (Apr 23, 2005 at 12:35 GMT) |
I love the idea of components, Ive been a big advocate of component model coding for a while, but I'm going to wait until you ship the component stuff for torque (rather than piss around and write my own).
On the aspect of phyiscs, I think youve made a great decision. Having the gtk stuff is great, but as I you point out, the instability of the current worst-case scenarios, along with the general performance of the present system kind of leave you no choice but to rework it differently.
I think that almost ANY object I can think of can be approximated by one or more of either boxes or spheres. It just makes sense to me to support those.
Are you using axis aligned boxes?
Also, the poly soup, is that for terrain/interior/exterior stuff? or for more precise dts collision checks once the basic sphere/box is collided?
Once you get "at rest" checking in, with perhaps some spatial culling in there, you should have pretty much an optimal system as far as flexibility goes. I agree that you'd maybe want convex hulls in there at some point too, just to keep the system more general. But I think youve pretty much got all the bases covered for a start.
I am just glad I dont have to do this kind of stuff (not my bag baby) and that we have Kristen who knows that stuff to sort it out.
But it sounds like some really useful groundwork, if only the components were part of torque!!! :)
Cool plan anyway Clark! good stuff!
| Clark Fagot (Apr 23, 2005 at 17:03 GMT) |
Re: poly soup, it's just for the static objects. So if you're collision image is a box, e.g.,. the box (not axis aligned but oriented, by the way) is collided against the terrain polys , interior polys, and track polys. You can still use a ts shape for LOS collision, or you can fall back on the box (or sphere) collision image for that.
In terms of optimality, it will never be all that optimal as long as the update is being done during the tick as I currently now do (e.g., it requires a recursion for displacing objects that you collide with but are still moving towards). It's fine when you are talking about avatar physics (which is the intent here) but if you were doing a Chain Reaction type game with, say, 50 objects piled on top of each other, I think you'd probably want to pull the physics out into some type of rigid manager so that it can avoid some of the update cruft, and then simply look up your new location during the tick. It'd require some re-organization of the tick update framework, and would be total overkill for dRacer, but I think it's probably the direction things should eventually take.
| David Chait (Apr 23, 2005 at 19:50 GMT) |
As for current physics engines not making great car demos, that's just because of what they are modelling. It's literally where the rubber meets the road that makes all the difference. ;)
-d
| Bob Dietz (Sep 24, 2006 at 00:38 GMT) |
Loved the video. I've started playing with the Torque code and realize this functionality will take a while (best case) to develop on my own. I'm still working on getting things to know when they collide and to make spheres roll appropriately when they move.
Any update on if/when this is going to become a core part of Torque?
| Guillermo Vilas (Apr 02, 2007 at 07:22 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
