How are the physics like in Cogs from Lazy8Studios(http://www.lazy8studios.com/) done? Any search keywords / opensource projects i could look at, maybe simple physics engines? I know I'm being vague...
Thanks.
Gear Physics
It isn't entirely obvious to me that Cogs has any physics simulation in it at all. At least not gear physics. Those gears are assembled in an orderly, logical fashion and the animations could simply be pre-baked keyframe animations, carefully ochestrated based on the way the gear sections are assembled. If I were doing that sort of game, this is the approach I would take. Sometimes physics simulation gets in the way.
That said, I'm sure I've seen a gear physics demo running on one of the available physics engines. I don't recall whether it was Bullet, ODE, Havok, PhysX, or something else...perhaps someone else will remember.
That said, I'm sure I've seen a gear physics demo running on one of the available physics engines. I don't recall whether it was Bullet, ODE, Havok, PhysX, or something else...perhaps someone else will remember.
I was thinking it might be relatively straightforward to model gears by using simple boxes joined at some central pivot, if you really want to go simulating them. These 'parts' should be available in most if not all physics engines, but I haven't got the faintest idea if this approach will produce any useful results.
Some ideas:
1. Don't simulate anything with physics, just fake it - so just animate.
2. Partial simulation - represent each gear as a physics rigid body. However, ignore collisions between the gears, but instead make constraints between pairs of gears on the angular velocities (i.e. the angular velocities need to be in the same ratio as the number of teeth on each gear), and solve these constraints just like everything else.
3. Full simulation with collision between the individual teeth.
The second option allows for unexpected interactions (e.g. throwing a box at the middle gear in a chain), and the same method can be used for things like pullies etc.
1. Don't simulate anything with physics, just fake it - so just animate.
2. Partial simulation - represent each gear as a physics rigid body. However, ignore collisions between the gears, but instead make constraints between pairs of gears on the angular velocities (i.e. the angular velocities need to be in the same ratio as the number of teeth on each gear), and solve these constraints just like everything else.
3. Full simulation with collision between the individual teeth.
The second option allows for unexpected interactions (e.g. throwing a box at the middle gear in a chain), and the same method can be used for things like pullies etc.
Quote:Original post by nathangoing
Thanks, I really was just curious how this may be accomplished.
The first choice you need to make is whether you want a kinematic (just velocities -- what some are calling "faking it") or a dynamic simulation (with acceleration). I'd just do the former; here's how:
Notation:
There are N gears. Gear i has ni teeth (a number that is proportional to both radius and circumference) and rotates with (scalar) angular velocity wi.
Constraints:
There are three kinds of constraints:
1 - Meshing gears. For any two gears i and j that are meshing,
wi ni = -wj nj
2 - Gears mounted on the same shaft. For any two such gears i and j,
wi = wj.
3 - Driven gears. If gear i is driven at speed ui, then you have the simple equation,
wi = ui .
Solving the constraints:
In general...
Unknowns: w1, w2, ..., wN
Equations: One for each constraint as above.
This is a linear system. Put it in a matrix and solve. If it has no solution, your gears are hooked together in an inconsistent way (which is entirely possible to do in real life), and they can't move at all. If the system is underdetermined (say, you have a free gear somewhere attached to nothing), I'd just go with the minimum-norm solution (this would e.g. make the free gear have zero velocity).
Efficiently...
I would not be surprised if your constraints are always in a tree structure (and have no cycles). In that case, you can just start from a known angular velocity (a driven gear) and recursively set the angular velocities of children.
If you in fact do have cycles, you can still do this; proceed in a breadth-first manner setting angular velocities. As in typical breadth-first-search, you don't want to expand visited neighbors; that said, when you do encounter a visited neighbor, check whether the angular velocity that has already been set for that neighbor agrees with the angular velocity of the current node times the appropriate gear ratio; if not, you have inconsistent constraints.
I would fake it. If two gears are touching, and gear A has N teeth and gear B has M teeth, then the ratio is N:M. This pretty simple.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
