24 November 2024 - The Entity System, Part 3: Physics. Again. Help.

Reintroduction

Some time ago I made two posts about the entity system. Originally I was chugging along forward with the data structure and moving ahead until I started implementing character physics.

So to recap (and introduce some new information):

I had the idea of using CharacterBody3D as my collider type for bones due to the existence of move_and_slide() provided by the engine. This method simulates physics for characters and is specifically designed for this one purpose.
I now use AnimatableBody3D which is effectively the same, but it derives from StaticBody3D which allows for some better handling due to trimming out a lot of behavior that is not necessary. It also has a similar but distinctly different move_and_collide() method which does roughly the same thing.

And now, a story.

This is the story of a developer named Xan. Xan was about to write physics simulation code for character models, something he was very excited to work on, something where the path ahead was so clear he knew precisely what had to be done to achieve his goal.

That was, until the time to write the code came along. "Let's use this built in method to simulate motion with other physics objects," he said. But he was distraught to realize that only some of the necessary information was used by the code provided by the engine.

See, the method accepts one parameter of motion, the linear velocity. This describes the direction the object is moving, and how fast. But something was missing...

"Hm, that's odd," he says to himself. "Where is the angular velocity parameter?" he wondered aloud.

Xan was soon to discover that there was not, in fact, an angular velocity parameter.

What Happens Now?

Ordinarily this would not matter so much, typically objects just apply their rotation first then simulate motion. It's not technically correct but for 99% of cases - especially with respect to characters which are not typically spinning - it is fine. With bones, however, there's a fundamental problem with this: Bones are constrained by rotating joints. Bones don't move and slide. They rotate.

To simulate characters, bones need to be able to spin which the physics simulator doesn't support on any type except RigidBody3D, which is not kinematic.

So you know how mass is just a number kind of like weight? Yeah so turns out rotation has its own type of mass called an "inertial tensor" and it's a 3x3 matrix.

I don't know why I keep running into hilariously specific scenarios where the most ungodly complicated math emerges and I am thrown into the deep end, but I'll be damned if I don't say I haven't learned more math in the past six months of this game's progress than I have in a school year. Good lord.

So yeah, that's my new goal: Implement rotational physics simulation that has proper accuracy. I will say now for those wondering, I am not implementing true correct physics simulations. Instead I am just moving a bit and checking iteratively (so more like SM64's quartersteps for rotation, and its 1/16th steps, and to optimize, rotation simulations are clamped to 360 degrees so comically fast rotation speeds aren't going to break it. No sideways long speens for you.)

The need for rotational tensors is for collision handling and making the moving parts experience torque forces when they hit at a point other than the center of mass.