Expose GridCellSize as Public Property?

Topics: User Forum
Nov 10, 2006 at 8:25 AM
Am I missing something?

I wanted to tinker with GridCellSize, because my balls are a bit sticky. (Sounds horrible...)

However, I couldn't find the public property which I should reset.

Digging a bit in the code, I noticed that CircleRigidBody(radius, edgeCount, mass) contains code for setting the GridCellSize:

collisionPrecision = Math.Min(AABB.Width, AABB.Height) * collisionPrecisionFactor;

Pseudo-code, as always.

collisionPrecision is not passed in as a parameter.

collisionPrecisionFactor is a private field.

Yes, I realize that I can just reset values right there in the source, but that can't be a permanent solution, can it? I want to be able to tweak things without ever touching your beautiful source.

I'm probably just not finding the right property, and it's all my fault, as usual... (c:

Cheers!
Jöran
Coordinator
Nov 10, 2006 at 12:15 PM
This is a known issue. I plan to fix it this weekend.
What I'm currently doing in the circle, rectangle, and polygon rigid bodies is estimating grid size based on the size of the AABB. That is the formula you see. It's something I knew I'd need to come back to.

I'll overload these objects and allow you to ether set your own collisionPrecision or set the grid cell size directly.

Coordinator
Nov 10, 2006 at 4:49 PM
After thinking about this some more, and after the discussion in this post: "Geometry Question/Problem" I think I will change the default constructors "Grid Size" estimation logic.

Currently I use .25 * the AABB's shortest side to compute a hopefully good grid size. This was found not to work well with some shapes (see the post I mention above)

Instead, I think I will use some fraction of the shortest edge on the geometry. Something like gridSize = .25 * geometry.GetShortestEdge().

This would probably make for a better default.

Then, of course, I will still provide overloads for those that want more control.

What do you think?
Nov 10, 2006 at 5:13 PM
As for overloading:

Okay, sounds good! Cheers for Jeff, working hard! (c:

As for default grid size:

I'll get back to you with what works for me. I've just finished making some balls bounce around a room with your engine, but I haven't played with the numbers yet.

Seems as the balls are a bit sticky, head-on collisions making them end up on top of each other, never separating. But then they are awfully small, with only an 8 pixel diameter.

Also, small balls don't always bounce logically. It looks kind of weird when one of them shoots off in a random direction on a floor-bounce, and the other one just smacks down with no bounce at all...

But I guess these things are general problems with the math in a lot of physics engines. Just look at the size of anything remotely round in Gish - huge!

Cheers!
Jöran
Coordinator
Nov 10, 2006 at 7:08 PM
When you say they are "sticky" to you mean they just don't bounce off eachother or do they actually stick together?

You can change the bounciness by changing the RestitutionCoefficent on the body. 1 implies a perfect 100% bounce, 0 implies no bounce (like clay)

However, the 0 restitution will sometimes bounce if the body is going to fast. This is due to how I am doing collision response. It's something I would need to look at but it's currently not real high priority for me.

Oh, and you are right, very small fast moving objects can be troubling due to "tunneling" It's another thing I nee to look at.

If you want a really small object you attach a very small texture to a PointRigidBody. PointRigidBodies will not collide with eachother, though only other RigidBody types.

Hope this helps.

Nov 11, 2006 at 10:49 AM
Jeff: "When you say they are "sticky" to you mean they just don't bounce off eachother or do they actually stick together?"

With head-on colisions, they get stuck on top of each other. I mean the position of the origin of each ball are identical, so you can only see one ball, drawn on top of the other. I've seen this before in other physics engines, so I'm not sure it's that trivial to fix.

You can take a look for yourself:

http://www.xnatutorial.com/wp-content/uploads/2006/11/mouoshimaidabeta2solution.exe

It's a 200 kb download, and it uses a vanila version of Farseer 0.0.1.2. Excuse the messy code, I'm working on refactoring while changing to beta 2 at the same time... (c:

Jeff: "You can change the bounciness by changing the RestitutionCoefficent on the body. 1 implies a perfect 100% bounce, 0 implies no bounce (like clay)"

When they bounce on the ground, they sometimes bounce high, sometimes low, depending on if they land right on a vertex or along a side.

Jeff: "However, the 0 restitution will sometimes bounce if the body is going to fast. This is due to how I am doing collision response. It's something I would need to look at but it's currently not real high priority for me."

It's not a high priority for me either. The balls are just placeholders, and they are gone by tomorrow.

Jeff: "Oh, and you are right, very small fast moving objects can be troubling due to "tunneling" It's another thing I nee to look at."

Again, prioritize the parts of the engine you need for your own game. If anyone needs something particular, we can always submit suggestions written in C# code.

Jeff: "If you want a really small object you attach a very small texture to a PointRigidBody. PointRigidBodies will not collide with eachother, though only other RigidBody types."

Yes, that's exactly what I ended up with. The balls were intended to end up as bullets sooner or later. It just happened sooner now.

Jeff: "Hope this helps."

Yes, it does. Thank you! A prompt answer inspires confidence. I have confidence in Farseer.

Cheers!
Jöran
Coordinator
Nov 11, 2006 at 2:02 PM
Ok, I see what you mean.

I think this could be caused by a couple things.

First, you might want to change the "_collisionPrecisionFactor" in the CircleRigidBody to something smaller. Instead of .25, try something like .1 Currently to do this you will need to change it in my source code. (Next release, sometime this weekend, will allow you to pass this value in via the constructor.)

Second thing is the balls are small and get moving pretty quick. Once a vertice gets two deep in the other ball, the collision system trys to pull that vertice out the opposite side of the ball and then the other vertices try to pull the other way and then you are stuck.

Currently, the only way to limit this is to either slow the balls down by applying less force (or adding some linear drag) or by decreasing the size of the timestep sent to the physics engine. Decreasing the timestep will make everything more accurate but will take more cpu cycles.

I have plans to look at this whole "tunneling" issue. Just not sure when I'll get to it.
Nov 14, 2006 at 11:07 AM
Thank you for putting time into this. Much appreciated.

Yes, I tweaked collisionPrecisionFactor, and ended up with 0.1, while increasing linear drag and not using a fixed timestep. It helped.

As I played with these numbers, I also played with the sice of the balls, and added some Rectangles as well. The final numbers I ended up with were much closer to "gridSize = .25 * geometry.GetShortestEdge()" than ".25 * the AABB's shortest side", so my vote is for changing the default to that. But you should collect fedback from many others before settling on a permanent value.

Someone else might like to chime in, but from my side, consider the thread closed.

Cheers!
Joran