Rigid shape box
by Marton Szucs · in Torque Game Engine Advanced · 07/31/2008 (3:08 pm) · 6 replies
Hi,
I would like to create a box with physics, but the result is funny:
I used the original RigidShape properties from rigidshape.cs.
I have 2 problems:
1. The box always stand up
I tested with restorativeForce=0, or/and bodyRestitution=0 too.
2. The box fall over the ground
I have a video (warning: loud sfx):
http://video.google.com/videoplay?docid=6468655620876262767&hl=en
Where can I found more information about rigid shapes?
Are they working good in multiplayer?
thanks for help
Marton
I would like to create a box with physics, but the result is funny:
I used the original RigidShape properties from rigidshape.cs.
I have 2 problems:
1. The box always stand up
I tested with restorativeForce=0, or/and bodyRestitution=0 too.
2. The box fall over the ground
I have a video (warning: loud sfx):
http://video.google.com/videoplay?docid=6468655620876262767&hl=en
Where can I found more information about rigid shapes?
Are they working good in multiplayer?
thanks for help
Marton
#2
The second issue, where the object passes through into the ground, is a problem with the Rigid class's collision handling. It's based on an old algorithm (http://www.cs.cmu.edu/~baraff/papers/index.html) that simply isn't sufficient for this kind of application. As I understand it, flat surfaces tend to create ambiguous collision cases which usually result in a failure to respond to the collision.
As far as I know, no one's come up with a solid solution. The TGB version of this code seems to be quite a bit more stable, but I imagine this is partially because there are no face collisions in a 2D system.
Objects with more rounded collision boxes tend to work a lot better, (I assume) because they create point-based collisions.
Short of totally replacing this system with something better (http://tdn.garagegames.com/wiki/Using_PhysX) you can minimize the failure rate by rounding off your collision meshes. I also periodically check to make sure none of my physics objects are below the terrain and "pop" them back up, but this is a really ugly hack.
08/07/2008 (7:53 am)
Yeah, the center of mass is in the wrong location. That should be easy to fix in a modeling app.The second issue, where the object passes through into the ground, is a problem with the Rigid class's collision handling. It's based on an old algorithm (http://www.cs.cmu.edu/~baraff/papers/index.html) that simply isn't sufficient for this kind of application. As I understand it, flat surfaces tend to create ambiguous collision cases which usually result in a failure to respond to the collision.
As far as I know, no one's come up with a solid solution. The TGB version of this code seems to be quite a bit more stable, but I imagine this is partially because there are no face collisions in a 2D system.
Objects with more rounded collision boxes tend to work a lot better, (I assume) because they create point-based collisions.
Short of totally replacing this system with something better (http://tdn.garagegames.com/wiki/Using_PhysX) you can minimize the failure rate by rounding off your collision meshes. I also periodically check to make sure none of my physics objects are below the terrain and "pop" them back up, but this is a really ugly hack.
#3
Thanks for helps, i think, i have to delete this feature from my game. :(
PhysX video is here:
http://video.google.com/videoplay?docid=4890145414926453128
08/08/2008 (12:43 pm)
I'm integrated the physX to my TGEA 1.7.1, but it has no player collision (the player has an ultimate mass, and it can only knocking the objects, but it can't stay on the box). The TGEA PhysX project's author abandoned the project ;(Thanks for helps, i think, i have to delete this feature from my game. :(
PhysX video is here:
http://video.google.com/videoplay?docid=4890145414926453128
#4
The PhysX implementation is just a basic framework -- it's up to you to decide how individual objects actually interact with each other, and which type of physics object represents them.
I did actually do something like this at some point, converting the player into a full PhysX object, and it worked relatively well.. if you want I'll see if I can dig that code out. It's not 100% as far as network prediction/interpolation, but it works well in singleplayer or a low-latency multiplayer system.
08/09/2008 (12:21 pm)
Traditionally player objects aren't true physics objects in the simulation; this tends to interfere with the type of control the user expects to have over the player body. It is true that the default setup in this resource isn't quite right itself, though.The PhysX implementation is just a basic framework -- it's up to you to decide how individual objects actually interact with each other, and which type of physics object represents them.
I did actually do something like this at some point, converting the player into a full PhysX object, and it worked relatively well.. if you want I'll see if I can dig that code out. It's not 100% as far as network prediction/interpolation, but it works well in singleplayer or a low-latency multiplayer system.
#5
Would you mind post the code here or email it to me? I need the feature too! Thanks in advance.
08/09/2008 (1:12 pm)
@Henry:Would you mind post the code here or email it to me? I need the feature too! Thanks in advance.
#6
08/09/2008 (2:18 pm)
I'll see if I can turn it into something easy to patch in. I kept planning to do this a while ago, but I'd wanted to fix the interpolation code and never found the time. At this point I should just get it out there and hope someone else can improve on it. As I said, it's perfectly suitable for singleplayer. 
Torque 3D Owner James Steele