I have some knowledge (creating my own multiplatform library) of game programming.

I want to start delving into animation, and so I thought I'd create the first component I could think of: A limb, i guess.

What are the (minimum) necessary components in such a concept?

My take:

class Bone
{
    Bone* parent;
    std::vector<Limb*> children
    
    vec3  position;
    vec3  orientation;
    float length;
    
    // possibly some precalculated matrices below for reducing calculations
}

What would you further add to this? Keep in mind I have all the prerequisites (eg. quaternions)

Joints, constraints, translation vector member of Bone?

What would you further add to this?

So are you doing both forward and inverse kinematics?

I think the way these things work in 3d packages can be done differently, or perhaps they can be done better.

Taking your queues from how actual bones work (muscular system) I think you can get a better idea of how to progress. Seems such a system would be more complicated, but if done right, could revolutionize the way kinematics are done.

For instance, our bones have natural constraints not limited by numbers. Our muscles are the constraints. The tension in our muscles determine the range of motion of our bones.

The orientation of our bones have built in limits. The only calculation we do is the calculations from our brain which direct our bones, which are limited by our muscles.

Also, every bone has a breaking point (something that is not seen in animation software which would be helpful to know when a pose is unnatural.) Tendons have a maximum stretching distance.

Perhaps there is mathematical research done on muscles and bones which you could implement? I assume there are predefined CONSTANTS for kinematics already.

I think that is stretching it a little. ;) I wouldn't mind going all the way, seeing as I usually do anyways.

For the moment I am just starting out trying for the first time to create something of a tail; where all the components are moving in relation to its parent, if any. As such I would just programatically modulate all the orientations and render it.

All in the name of knowledge and wheel reinventing.

Hehe. Nice pun. Well, once I made an object trail the mouse with a delay in a non-conventional way. It made my code very small, and it also worked a lot better and faster. I used absolute value somehow (I need to find the file because I forgot how I did it).

But I think that using absolute value will remove potential issues, because the only thing that makes motion negative is it's direction. So using absolute values and making them negative for different directions is a neater way to do it. Chances are you already are doing that though. I'm sure you are more advanced than I am, but you never know, maybe it will help. haha.

Each link (limb) in your linkage should be connected to a Joint object, which would store the constraints. I would think the linked list pointers would go Limb1 -> Joint1 -> Limb2 -> ... etc. You could probably set up the position analysis equations by traversing the list to get all the constraints and then pass them and the input angles into a numerical solver to yield the final positions of each linkage.

Speaking as an engineer, kinematics is somewhat hard to do because the equations can become nonlinear really fast. Inverse kinematics is harder because you have multiple valid solutions for a given position, so you have to do some kind of least-squares method to get a good solution. However, most of the techniques that I know are there so that if you're designing a path for a robot, you don't crash the robot into itself. Maybe for animation more simplified equations are sufficient.

If I was to model joint animation assuming if it is in 2D, I would get the first limb to work first. There many ways to do it. If I were to do it, I would do it the most easiest and simplest way which is to fake it by letting the artwork do all of the illusion work. Then have my animation code drive the artwork or more technically speaking iterate through every frame of the artwork of the limb to make it move. This ensure my animation code is reusable regardless of what artwork it is because the effect I create is dependent on

artwork and not code.

Some people would probably make it dependent on code and not the artwork.

After all, games is all about smoke and mirrors.

I remember when I watch Diablo III making of how they got the Demon Azmodan to bend forward even given its anatomy. In short, the Diablo III crew had their own tricks up their sleeves.

At the most basic level, animation is a list of images and time pairs.

I guess it really depends on how detailed you want your kinematics to be. You can make your models accurate or you can do some illusion and tricks to make it seem accurate. It depends on your application.