Collision inaccurate with small dimensions
by Jameson Bennett · in Torque Game Engine · 01/24/2005 (6:29 am) · 9 replies
We are currently working integrating a physics engine with the collision engine and have run into issues with the data passed back in the collisionInfo call:
Objects that are small, around .25 units or smaller do not return very good collision data. Larger objects seem to return the data fine. The small objects act very squirrely when the physics engine handles them due to the collision data.
My question: Is there a scalar or some other tweakable parameter that can be adjusted to adjust the 'range' in which the collision engine is accurate? I see there is a scalar passed in when getting the collision data, but I am unsure of the repercussions of scaling the data passed into this function.
Our other option is to scale the art pipeline to 4x - 10x standard meter size. This would be a pain for our artists and may cause a good deal of confusion as we are dependent on the world scale for a lot of the functionality of our application. This is a 'last resort' as i figure this problem can be addressed in the collision engine itself.
Anyone familiar with the collision engine please advise!
Thanks in advance,
Jameson
Objects that are small, around .25 units or smaller do not return very good collision data. Larger objects seem to return the data fine. The small objects act very squirrely when the physics engine handles them due to the collision data.
My question: Is there a scalar or some other tweakable parameter that can be adjusted to adjust the 'range' in which the collision engine is accurate? I see there is a scalar passed in when getting the collision data, but I am unsure of the repercussions of scaling the data passed into this function.
Our other option is to scale the art pipeline to 4x - 10x standard meter size. This would be a pain for our artists and may cause a good deal of confusion as we are dependent on the world scale for a lot of the functionality of our application. This is a 'last resort' as i figure this problem can be addressed in the collision engine itself.
Anyone familiar with the collision engine please advise!
Thanks in advance,
Jameson
About the author
jam3son.com
Recent Threads
#2
Are you using the convex or polylist collision systems?
01/29/2005 (12:48 am)
How small of objects are you dealing with? You may be running into F32 precision issues.Are you using the convex or polylist collision systems?
#3
We are using the convex collision system.
A general solution would be best, where we could input a scalar on mission startup that the collision engine would be accurate at, rather than pinning down to a specific size. We are working towards that goal with the implementation.
Thanks for the tip on the F32 precision, we will look at that.
01/29/2005 (3:48 pm)
The size we get problems is at about .1 x .05 x .4 units. We havent pinned it to an exact size.We are using the convex collision system.
A general solution would be best, where we could input a scalar on mission startup that the collision engine would be accurate at, rather than pinning down to a specific size. We are working towards that goal with the implementation.
Thanks for the tip on the F32 precision, we will look at that.
#4
01/29/2005 (5:43 pm)
Yeah, I'd say that for that scale you're going to start running into precision issues. What are you trying to simulate that's so small? Could you fake it with a particle system?
#5
Basically, we were trying to do a 1 to 1 ratio between real world meters and in-game meters, and then make regular handheld object size type of stuff. So our objects are all typically smaller then 1 meter, usually around half a meter. Anything you could pick up and throw, like a good size rock or piece of wood, soda-can size type stuff.
Our objects are in-game objects the player can use, so we probably couldn't use a paricle system for them.
So you think the problem is in the collision code itself? We tested the physics engine (ODE) and found the error wasn't being caused there.
We have spent a lot of time on this problem, and it has a been a big pain. It will be SOO nice to have it resolved. We chased it around a lot until we realized it was most likely coming from the TGE collision code. Any input is always greatly appreciated. :)
01/31/2005 (12:18 pm)
Hey Ben, I'm working with Jameson on this one...Basically, we were trying to do a 1 to 1 ratio between real world meters and in-game meters, and then make regular handheld object size type of stuff. So our objects are all typically smaller then 1 meter, usually around half a meter. Anything you could pick up and throw, like a good size rock or piece of wood, soda-can size type stuff.
Our objects are in-game objects the player can use, so we probably couldn't use a paricle system for them.
So you think the problem is in the collision code itself? We tested the physics engine (ODE) and found the error wasn't being caused there.
We have spent a lot of time on this problem, and it has a been a big pain. It will be SOO nice to have it resolved. We chased it around a lot until we realized it was most likely coming from the TGE collision code. Any input is always greatly appreciated. :)
#6
01/31/2005 (1:13 pm)
I spoke with Tim Gift about this. There are some tolerances in the engine that are set to be about a tenth of a meter. You should be able to turn those down. One important factor to consider though is that if you have high precision near the origin of worldspace you'll run out pretty quickly when you move further out.
#7
Not to try to design your game for you, but why do these objects have to be to scale? If your design can handle it, consider making them bigger than scale when on the ground, then have scaled down versions when you are holding them in your hand.
01/31/2005 (2:25 pm)
I think the main problem is that GJK (the collisions algorithm) breaks down when a small object collides with a large object (reference). That reference also discusses how to fix the situation.Not to try to design your game for you, but why do these objects have to be to scale? If your design can handle it, consider making them bigger than scale when on the ground, then have scaled down versions when you are holding them in your hand.
#8
We are creating more of a 'sim' than a game in some ways...need somewhat accurate data on the happenings in the environment since our 'players' collect and analyze the data such as position/time data, etc. I know it is better to fake a lot of this stuff but we need to keep stuff relatively close to reality to get the most from our implementation of the physics engine and to prevent ourselves from falling into special case hell.
Thanks again for the replies...you help is much appreciated!
01/31/2005 (2:46 pm)
Thanks for the reference on GJK...Ill look it over.We are creating more of a 'sim' than a game in some ways...need somewhat accurate data on the happenings in the environment since our 'players' collect and analyze the data such as position/time data, etc. I know it is better to fake a lot of this stuff but we need to keep stuff relatively close to reality to get the most from our implementation of the physics engine and to prevent ourselves from falling into special case hell.
Thanks again for the replies...you help is much appreciated!
#9
@Clark: Thanks for the reference. I actually have Van Den Bergen's book, althrough I've read only a couple pages.
01/31/2005 (2:58 pm)
Thanks for throwing out some ideas everyone. I work with Jameson and Drew. I've been the main shmuck that's gotten to dig into the collision code thus far. I have a pretty solid understanding of the collision system now (pretty nifty once you figure it all out), but haven't looked too deeply into the GJK algorithms.@Clark: Thanks for the reference. I actually have Van Den Bergen's book, althrough I've read only a couple pages.
Torque 3D Owner Jameson Bennett