tbe
tbe copied to clipboard
Balls ignore all friction
Probably not easy to fix, but here we go:
It seems that all balls just completely ignore friction of floors and other things. They basically can just roll forever, no matter how slow. Meaning you can get a ball across a huge distance if you just wait enough.
Why this is not easy to fix:
- Zero friction may have its legitimate uses, but IMO it should not be the default
- After the fix, many levels WILL become broken because they rely on rolling balls with that zero friction. Meaning all levels have to be checked and tweaked after this. Probably not much fun.
add <hints>
sections to all levels and we can test automatically :smile_cat:
There are three different types of friction in the world:
- static friction
- kinetic friction
Static friction (an object at rest stays at rest, even on a slope) is implemented in the physics engine and uses the same constant as the first of dynamic friction below. This friction is called Coulomb friction.
Kinetic Friction can again be split in two:
- a ball on a slope starts rolling, not sliding - this is also due to friction. Box2D re-uses the same constant as for Coulomb friction.
- a ball on a horizontal floor should slow down - also friction (or damping). This type of friction doe exist in the physics engine - for rolling objects. In Box2D, it's called bodyDef.angularDamping and apparently a good default value should be 0.01f.
@Wuzzy2: can you please explain what you think the type of friction is, you ask for (I think you mean "kinetic - slow down"). In that case: good news, it is implementable! I adjusted my above remark.
Note that adding angular damping could also make the Pingus implementation slightly simpler.
Apparently I should re-read the box2d manual more often :stuck_out_tongue_winking_eye:
I was talking about kinetic friction, that is, balls should slow down when they roll on floors. I am not sure if this works already for other objects.
With “zero friction” I mean the current behaviour: Balls never slow down on floors.
OK, let's add this to the next milestone. I agree it will make things more real-life.
I have looked into this but those nasty balls seem to resist all my attempts to have friction added. :D
My first thought was, that just adding ballFixDef->friction = 0.3;
into createBallShapeFixture
would do the trick (ok, not really of course, but just for testing to get started), but it doesn't do anything. :-(
Besides, the friction code in the game overall seems to need more love and/or refactoring because it seems pretty messy. From what I have investigating, I noticed:
- Friction is rarely set explicitly
- No default value of friction visible in editor, but there clearly are objects which do have friction
- Friction is not set as property in
AbstractObject
- Factories include bounciness, mass, etc. but not friction (only indirectly through “additional properties)
- I have yet to figure out where the actual friction for
RectObject
s andPolyObject
s comes from—for fun (and testing) I even emptied bothsetFriction
methods which seem to be the only places in the entire code where the friction of a fixture is actually being touched. Yet those object still have friction (while balls don't). This is very weird to me, maybe there is some default friction somewhere and I just haven't noticed? - Weird
setFriction
methods. Their mere existance seems weird, since there's also nosetMass
(ok, there is one inTriggerExplosion.cpp
, but that does not have a generic factory likeRectObject.cpp
) orsetBounciness
, so why this special treatment?