Friction and Traction

[Nemox]

So I'm working on friction and traction for my game. Right now what I have is a character whose orientation changes according to the surface he's walking on. I figure I'll base acceleration on how much friction the surface has, so slick surfaces like ice will cause the character to accelerate and decelerate more slowly.

But I also want to incorporate a level of Traction that a character can have. In my mind, "traction" is the ability for a character to hug the ground, and generate the "downforce" that keeps him stuck to ceilings. This would also be the force to resist gravity. So, a character with 0 Traction would not be able to do any of this. But a character like Espio with 10 Traction would be able to completely resist gravity, and have a lot of downforce to work with.

But it seems a little redundant; a force that sticks a character to the wall, and a force that resists gravity. But without that redundant force, a character's acceleration and friction might not be enough to keep him in place.

So I kinda want to hear what you guys do for traction, or downforce, or other such silliness. There must be quite a few methods to do it, and that could give all of us some new perspective on how to make it work. What do you guys do?

[DimensionWarped]

Friction/traction has nothing to do with things like a roller-coaster being pushed against a loop throughout the whole of the motion. In fact, it barely even has anything to do with gravity aside from that being the source of energy. There is no force that resists gravity, there is simply kinetic energy that is converted to potential energy to going moving the force of gravity and redirected due to what is basically a continuous collision against an almost perfectly parallel angle to the direction of velocity.

The way it's done in Sonic games is that the game simply turns gravity off for the purpose of things like falling when on the ceiling and the mode simply switches back below a certain speed. The program knows the angle the player is at through... well, a number of possible means depending on the scenario, and when the player is moving based on his speed value, he is moved at the magnitude of the speed value in the direction of the angle (mag * cos(angle) for x, mag * sin(angle) for y).

Sonic isn't a realistic character physically. He sticks to surfaces regardless of the physics behind it. For instance, if he is going around a convex embankment (player starts on top, runs to the right, runs down and to the right, runs down and to the left, and then is running on the ceiling to the left... or the same thing in the opposite direction, or perfectly mirrored.) he'll continue to stay on the surface even though there is no reason for him to conform to the surface going down and certainly not when looping back around and onto the ceiling. He can run on ceilings indefinitely regardless of the situation (in real physics, you'd only be able to roll on a perfectly flat ceiling for an instant before you'd start falling... which is why roller coaster loops tend to be round all the way through).

The way I'm going to do it is more or less the traditional way. Four basic modes of movement for each of the cardinal directions of 2D (up down left right), realSpeed is impacted by gravity when moving on either wall, but not when moving on the ground, tracks for angle, changes which movement mode it's on at 45, 135, 225, and 315 degrees, etc.

[Nemox]

Friction/traction has nothing to do with things like a rollercoaster being pushed against a loop throughout the whole of the motion. There is no force that resists gravity, there is simply kinetic energy that is lost to the force of gravity and redirected due to what is basically a continuous collision against an almost perfectly parallel angle to the direction of velocity.

The way it's done in Sonic games is that the game simply turns gravity off for the purpose of things like falling when on the ceiling and the mode simply switches back below a certain speed.

My system has a really emergent sort of PhysX-based controls, so I'd want to create such a force instead of simply reducing gravity. Thinking about the way it works so far though, perhaps I could Slerp the Gravity vector to the character's "down" vector based on velocity and this Traction stat. Maybe the velocity redirection could be based on this as well, but I would have to test that out to be sure...

This could generate more force than needed though. Perhaps I could make the force directly proportional to the distance between the ground and the character. Sometimes the collision doesn't pick up on some things, so I use raycasts to keep the character grounded when it's less than 0.4 units away. I suppose that's really why I need such a downforce.

EDIT: I read through your edit, and I'm thinking up some more thoughts. Room immediately around my head is beginning to smell like smoke.

[DimensionWarped]

What edit?

[Nemox]

What edit?

When I first read your post, it only had what I quoted in my previous post. I figured you edited it or somethin'. xP

Looking at your description of movement in Sonic games, it seems quite similar to my idea of Lerping the gravity vector in some cases (Don't know what I was thinking with Slerp...). While upside-down, gravity would be Lerped toward the character's down direction. At low speeds, the amount would be less, so gravity pulls the character out faster. At higher speeds, gravity would take somewhat longer to pull the character out. And at super-high speeds, gravity would have no effect, allowing the character to continue indefinitely until thwacked by a robot.

This would effectively do the same thing, but perhaps slightly more emergent with the physics system I'm using.

Although, that would pose the problem of indefinite vertical motion... I'll play around a bit. Maybe I should mess with gravity a bit too. It's a bit too floaty for a platformer now.

[DimensionWarped]

Oh, I must have edited without realizing it...

Still, I find it a little weird that you wrote "EDIT:" when you hadn't actually made the post yet. According to my instruments, that post you made is edit free.

[oddwarg]

My latest physics engines(regardless of being 2D or 3D) have been largely based on gravity(which generally does not change) and normal forces. The standard case is where the terrain exerts a normal force on an object to prevent it from going through the terrain. If I want to allow unrealistic things like what DW has described, then I allow negative normal forces. The negative normal force is limited to some function of the speed, so you can't stand still in the ceiling. That would just feel stupid.

A "negative normal force" forces an object towards the ground just enough to keep it from falling off. Apart from the limiting mentioned, it always has the exact same formula as as regular normal force, which is why I don't give it some other name.

As for acceleration, I've been trying a number of different approaches. In reality, acceleration would be related to friction, which is proportional to the normal force, but since I like running on walls and ceilings(where the normal force is generally not positive), I've usually ended up using some function which allows a certain positive amount of acceleration based on the angle of the ground. And, in case it wasn't clear, the direction of acceleration would be parallel to the direction of the ground, while a jump would always be directed away from the ground.

My terrain modelling for these physics engines has been based on line segments and points(possibly triangles), while most other objects are modelled as circles(or spheres). The result is that the engine must do a lot of vector arithmetic for the collision detection and handling(and as a programmer I have to program it), but it also means I can rotate any shape however I want and it will still work as expected.

The main thing I like with my approach to things is that there is no need for "modes". The general case covers all cases.

I believe this is not the way "everyone else" makes physics for sonic games(I haven't really looked into it but it seems that way), and it is not a good way to mimic the classics or anything. But I thought you might be interested anyway. And it's just a very rough description but hopefully you get the general idea.

[DimensionWarped]

You can do Sonic physics without the four modes that were used in the classics just as the 360 engines here do. You just won't get an accurate reproduction without applying the rules as they were applied in those cases. In 3D, the notion of using modes for every type of movement in 90 degree splits is absurd anyway.

In fact, the real reason for the 4 modes isn't even to apply the rules since most of that could be done much more simply. The real reason for doing it was because angle detection wasn't particularly viable with the Megadrive processor and so they had to store height arrays for every type of tile to simplify the process. The modes were mostly used to decide how the sensors would line up for the purpose of checking the height arrays. This also greatly simplified the whole process of collision detection with the terrain.

[Nemox]

@DW: Weird, maybe it's 'cause I edited it really fast. I tend to do that at times.

@Oddwarg: That sounds about the same as what I'm doing, except that I am trying to account for characters who can stand still on walls and ceilings like Espio. And for characters like Mighty who have a good ability to at least resist gravity. Sonic for instance, would be easily pulled back by gravity if he tries to run up long enough. But Mighty is able to resist the pull more.

The way my system works, it applies the force of Acceleration up to top speed, and applies gravity as well. When running against gravity, the character will slow to a stop. But if Acceleration is higher than Gravity, the character can speed against gravity at will. Which means if I reduce the force of gravity for certain characters, acceleration will be too powerful by comparison.

However, a square or cube root for the Lerp rate could work out...

I suppose this could call for some tests with scale to determine how much I want gravity to affect the character, and how fast acceleration and top speed will work. Scale could be an important factor in this...

@DW again: Luckily my system is pretty lightweight for being so physics-based.

[luksamuk]

Wait. Isn't traction the force in a rope that is being pulled?

And um... idk if this would help, but the minimum speed required for an object to run through a loop is the square root of the multiplication between the loop's radius and the gravity force. And also remember that Sonic works like he was a simple ball rolling or a rollercoaster cart.

[DimensionWarped]

That's tension. Traction is more like tires gripping the road. It's basically the result of normal forces (normal relative to outward forces as in when turning) on a very small level which is basically the exact same thing as friction.

Traction is what let's you move forward from a state of rest and what let's you turn. Without traction, it's kinda like... you are on a big pile of ice, trying to move sideways by sliding your hands on a big wall of ice. All that you can do is push yourself off the wall, you can't really slide along it. Only more so, because ice has some level of traction.

[Nemox]

I just did some fooling around in Sonic Colours, and it seems that in those more free-controlled areas, Sonic adheres to a slope only if he's traveling fast enough. Otherwise, he stays upright. Also, he can only generate enough force to move forward if he's on a low enough slope. Seems very simple and clean.

I suppose I should set my running force to Force*CombinedFriction/(1-(slope/90))

At the point of 90, the character is touching a wall, so they apply 0 force if that's the only footing they have. It's a built-in maximum.

Alternatively, the character can apply force relative to how steep the slope is relative to himself.

So if he's traveling fast enough, he will adhere to the slope, and apply full power. If he's too slow, he will be walking against an angled surface, and apply less running power.

Perhaps I should also account for how easy it is to adhere to downward slopes as opposed to upward ones... Oh well, no need to over-complicate it yet.

EDIT: I've now got friction and deceleration working flawlessly. Now if something is slick, the character will accelerate and decelerate more slowly, but will still reach top speed eventually. And deceleration will not work against gravity. Next up, I'm going to add the traction, and allow deceleration to work against gravity if you have a high enough traction.