Problem
Creatures need to move, and movement needs to feel physically grounded rather than scripted. A wolf running, a fish swimming, a worm pushing through soil should all emerge from how forces interact with the creature's body and the MPM material around it.
Approach
Movement in LP is force-based. A creature applies internal forces to its body parts, those forces interact with the MPM grid (terrain, water, other matter), and the resulting motion comes out of the physics. No hardcoded speed values, no animation state machines.
For the player: you inhabit a creature. Your inputs translate into internal forces the creature applies. A bipedal creature walking feels different from a quadruped because their mass distribution and limb configurations are different, not because we scripted two separate controllers.
Core ideas
Input to force translation:
Player input (or AI drive) produces a desired direction/effort. This maps to force applied at appropriate body parts via the forces crate. The creature does not teleport; it pushes.
Anatomy-aware:
A creature with two legs pushes differently than one with four. Losing a limb changes the force application points. This falls out naturally if movement is just force application rather than a bespoke controller per body type.
Terrain interaction via MPM:
The MPM grid handles friction, resistance, and buoyancy. Moving through water is slower not because we coded a swim speed, but because the fluid MPM applies drag forces. A creature on loose soil sinks slightly. This is all physics, not scripted terrain types.
Multiplayer:
When multiple players inhabit creatures in the same simulation (wolfpack, ant colony), movement authority lives with the physics world. Each player sends intended forces; the server integrates them. No special multiplayer movement code needed.
Dependencies
Scope for first pass
Walking on solid terrain only. Limb count affects stability and balance. Environment resistance comes from MPM when ready. Swimming and flying extend the same system later.
Problem
Creatures need to move, and movement needs to feel physically grounded rather than scripted. A wolf running, a fish swimming, a worm pushing through soil should all emerge from how forces interact with the creature's body and the MPM material around it.
Approach
Movement in LP is force-based. A creature applies internal forces to its body parts, those forces interact with the MPM grid (terrain, water, other matter), and the resulting motion comes out of the physics. No hardcoded speed values, no animation state machines.
For the player: you inhabit a creature. Your inputs translate into internal forces the creature applies. A bipedal creature walking feels different from a quadruped because their mass distribution and limb configurations are different, not because we scripted two separate controllers.
Core ideas
Input to force translation:
Player input (or AI drive) produces a desired direction/effort. This maps to force applied at appropriate body parts via the forces crate. The creature does not teleport; it pushes.
Anatomy-aware:
A creature with two legs pushes differently than one with four. Losing a limb changes the force application points. This falls out naturally if movement is just force application rather than a bespoke controller per body type.
Terrain interaction via MPM:
The MPM grid handles friction, resistance, and buoyancy. Moving through water is slower not because we coded a swim speed, but because the fluid MPM applies drag forces. A creature on loose soil sinks slightly. This is all physics, not scripted terrain types.
Multiplayer:
When multiple players inhabit creatures in the same simulation (wolfpack, ant colony), movement authority lives with the physics world. Each player sends intended forces; the server integrates them. No special multiplayer movement code needed.
Dependencies
AppliedForce,Velocity,Masscomponents ready to useScope for first pass
Walking on solid terrain only. Limb count affects stability and balance. Environment resistance comes from MPM when ready. Swimming and flying extend the same system later.