Plan for Gary "ChunkyKs" Briggs
by Gary "ChunkyKs" Briggs · 05/23/2005 (10:12 pm) · 5 comments
Well, since they were appended prett late on the old .plan, and I just got myself a mac and made it do that development thing, I'm just putting up all three demos of ODEScript.
I'm completely stoked that all this is actually working. You know, the hardest thing about working on Physics code is that as soon as it starts to work properly, it quickly gets to be a whole lot of fun to play with it instead of work on it.
Linux
OSX
Windows
It's a chain of objects, connected at one end. Move the mouse around the screen, and hit space to make gravity go in that direction [from the center of the screen], with magnitude proportional to how far from the center it is. It's pretty obvious what's happening once you start playing with it. Hit "d" to toggle damping, and you can set $dampingfactor in the console if you wish to change it. The current -0.1 is pretty intense for the task at hand [every time the physics ticks, one tenth of every body's anglular and linear energy gets dissipated. That's a lot]
And now for the T2D Physics thoughts...
What follows is my understanding from brief code poking. Feel free to correct me if I'm wrong.
I've got collisions working thanks, among others, to a nasty hack from King Tut BoB. It works, but it's not ideal, and doesn't work well with interesting polygons. If anyone [Josh, Melv...] would be able to tell me a good way of getting collision depth, that would be great. That includes the case where one object is completely inside another. I imagine a problem where one object has entered the other, and has travelled more than half way though.
The current collision code in T2D basically moves objects away from each other distances inversely proportional to their masses. Under normal conditions, this will, after an unknown amount of time, correctly "solve" all collisions. This is more than good enough for most stuff that anyone will do, but isn't really useful enough to get really good physics abuse down with other toolkits.
Notice that what it *doesn't* do is move them apart a distance that's actually related to penetration depth, just their masses. I suspect this may well be deliberate, to fix the problem that might occur if you had multiple objects all colliding in multiple objects at the same time. I don't have a problem with this, I think it's a nice reliable, quickly calcuable, solution to the problem.
If you tried the T2D Physics demo, you'll have noticed that if you get many many objects on screen and continuously apply forces in the same direction, then they actually start going way way into each other, eventually possibly passing through. This is why it's pretty easy to bash blocks until they pass through the walls, in the demo.
So, anyways. What I want to know is, is there a good way to get collision depth in T2D? If not, uhm, well, does anyone have any recommendations on what I could do? If you play with the demos above, you'll find that the chain can get into the spaceship from the far end pretty easily, and it's bugging me. Doesn't matter for small energy collisions, but for other advanced messing about...
Gary (-;
I'm completely stoked that all this is actually working. You know, the hardest thing about working on Physics code is that as soon as it starts to work properly, it quickly gets to be a whole lot of fun to play with it instead of work on it.
Linux
OSX
Windows
It's a chain of objects, connected at one end. Move the mouse around the screen, and hit space to make gravity go in that direction [from the center of the screen], with magnitude proportional to how far from the center it is. It's pretty obvious what's happening once you start playing with it. Hit "d" to toggle damping, and you can set $dampingfactor in the console if you wish to change it. The current -0.1 is pretty intense for the task at hand [every time the physics ticks, one tenth of every body's anglular and linear energy gets dissipated. That's a lot]
And now for the T2D Physics thoughts...
What follows is my understanding from brief code poking. Feel free to correct me if I'm wrong.
I've got collisions working thanks, among others, to a nasty hack from King Tut BoB. It works, but it's not ideal, and doesn't work well with interesting polygons. If anyone [Josh, Melv...] would be able to tell me a good way of getting collision depth, that would be great. That includes the case where one object is completely inside another. I imagine a problem where one object has entered the other, and has travelled more than half way though.
The current collision code in T2D basically moves objects away from each other distances inversely proportional to their masses. Under normal conditions, this will, after an unknown amount of time, correctly "solve" all collisions. This is more than good enough for most stuff that anyone will do, but isn't really useful enough to get really good physics abuse down with other toolkits.
Notice that what it *doesn't* do is move them apart a distance that's actually related to penetration depth, just their masses. I suspect this may well be deliberate, to fix the problem that might occur if you had multiple objects all colliding in multiple objects at the same time. I don't have a problem with this, I think it's a nice reliable, quickly calcuable, solution to the problem.
If you tried the T2D Physics demo, you'll have noticed that if you get many many objects on screen and continuously apply forces in the same direction, then they actually start going way way into each other, eventually possibly passing through. This is why it's pretty easy to bash blocks until they pass through the walls, in the demo.
So, anyways. What I want to know is, is there a good way to get collision depth in T2D? If not, uhm, well, does anyone have any recommendations on what I could do? If you play with the demos above, you'll find that the chain can get into the spaceship from the far end pretty easily, and it's bugging me. Doesn't matter for small energy collisions, but for other advanced messing about...
Gary (-;
About the author
#2
It depends on what you mean by "get" collision depth. The physics code solves overlaps (which normally shouldn't happen) in one of two ways. The first is to solve the overlap over-time and moves the object according to its mass. The second is to instantly solve the overlap. You can see this in action via the "world limits" which use the internal rigid-physics to instantly solve the overlap.
We didn't feel that this information would be something that's typically needed in the collision callback but is pretty easy to add in.
- Melv.
05/24/2005 (6:13 am)
Gary,It depends on what you mean by "get" collision depth. The physics code solves overlaps (which normally shouldn't happen) in one of two ways. The first is to solve the overlap over-time and moves the object according to its mass. The second is to instantly solve the overlap. You can see this in action via the "world limits" which use the internal rigid-physics to instantly solve the overlap.
We didn't feel that this information would be something that's typically needed in the collision callback but is pretty easy to add in.
- Melv.
#3
05/24/2005 (8:18 am)
nice demo! I can definitely see how some of this will apply to a game we have in development. nice work.
#4
@Melv: Cool, I hadn't found that bit yet. I'll take a look at it. Thank-you very much!
Something that I'm studiously avoiding is adding any code to anything else. I'm not modifying T2D's code at all, just appending more. ConsoleMethod's ability to just add features by linking, and not modifying any other code, rocks. For example, I wouldn't add anything to the onCollision callback, just make a new function "getPenDepth(%srcObj, %dstObj)". My rationale for this is mostly twofold:
1) I'm stupid, and my code would probably break someone else's
2) I'm stupid, so I hate GG resources whose instructions are "modify code XXX thusly", since I always mess it up, and always have problems. Instructions "add this to your build, magically stuff happens" are much more to my liking. :-)
You might have begun to sense a theme, there.
Incidentally, I very much didn't intend to sound negative about T2D's physics; I think it's great, it's just "different" from ODE, so it doesn't supply stuff I need for ODE as easily. That's not a bad thing at all, just a little more work for me.
Gary (-;
05/24/2005 (12:15 pm)
@Matt, Joshua: Thank-you very much! Compliments are the stuff that my warm fuzzies are made of :-)@Melv: Cool, I hadn't found that bit yet. I'll take a look at it. Thank-you very much!
Something that I'm studiously avoiding is adding any code to anything else. I'm not modifying T2D's code at all, just appending more. ConsoleMethod's ability to just add features by linking, and not modifying any other code, rocks. For example, I wouldn't add anything to the onCollision callback, just make a new function "getPenDepth(%srcObj, %dstObj)". My rationale for this is mostly twofold:
1) I'm stupid, and my code would probably break someone else's
2) I'm stupid, so I hate GG resources whose instructions are "modify code XXX thusly", since I always mess it up, and always have problems. Instructions "add this to your build, magically stuff happens" are much more to my liking. :-)
You might have begun to sense a theme, there.
Incidentally, I very much didn't intend to sound negative about T2D's physics; I think it's great, it's just "different" from ODE, so it doesn't supply stuff I need for ODE as easily. That's not a bad thing at all, just a little more work for me.
Gary (-;
#5
By molesting some ODE collision parameters, I've pretty much fixed this problem. *growl*
Gary (-;
05/24/2005 (4:26 pm)
Ever spend a whole bunch of time trying to fix a problem completely the wrong way?By molesting some ODE collision parameters, I've pretty much fixed this problem. *growl*
Gary (-;
Torque Owner Matt Van Gorkom