>>32995
>Writing this stuff down helps me think about what to think about. If that makes sense
It does!
POTD
<--->
Excellent ideas, Grommet. Actually, you've described in-effect many aspects of how a modern character-rigging system works. And yes, the fundamental, underlying offset description for any given element boils down to a 4D vector (3D point + Weight). And yes, it's a highly-compact descriptor with literally decades of usage in robotics & graphics engineering (and at least hundreds of years before that in maths).
As you'll see in during our hand development project (
>>33001 ), the
FK/IK Solver's job is to integrate all the related parts 'up & down the chain', and produce a 4Dvec offset as the target-goal motion path (this is often represented as a simple graphical line inside the user display of Blender, Maya, et al, as a part of your character's rig) (in an animated system [such as with a robowaifu's sub-element's (arms, legs, etc.) motion descriptions], this will actually be a time-based
collection of these 4Dvecs; AKA a
motion curve). Further,
all the other parts in the chain (eg, let's say a simple Finger has a 3-element Joint array called
knuckles {proximal, middle, distal} * ) each make their own contributions -- which all add up together into the final
FK solve -- regarding where the tip point of that finger (on the very distal end of the distal knuckle segment itself) actually winds up. **
<--->
And of course as you implied, you generally
already know in advance in most cases where you want your robowaifu's fingertip to go anyway, and this is where
IK solves come into play (you pick the spot, and the system of FK-bound joints [the skeleton] tries to get there... as if the fingertip point itself 'drags' them all along, for it to reach the desired goal location). FK & IK work together, you see. :)
Character rig internals tend to be highly-optimized & compact (they have to be!) and Geometry/Trigonometry/Linear Algebra calculations sits at the heart of all the underlying designs of the data structures used (like points & vectors).
I hope this will all be clear as the project mentioned above proceeds, Anon. Cheers. :^)
---
* These joints are all serially 'connected' together via 4Dvecs known as
links. In a good simulator rig, these link lengths will accurately match the lengths of the realworld physical skeleton elements in question (such as with the finger's individual knuckle segments).
** But
as we all know IRL, all sorts of messy interactions with physics & mechanics come into play immediately; and so your beautiful, mathematically-pristine navigation planning solutions all come to naught! (
DANGIT!111!!ONE!!!) :DD This is a big part of why we want to devise simulator systems here : (
>>155, et al ) to help cut down on surprises (also very helpful at runtime too : so a robowaifu can quickly make accurate prediction-planning for her next-upcoming desired motions [we ourselves learn & refine our own, similar, 'position/action/reaction' mental-model of bodily dynamics (proprioception) all throughout our lives]).
---
And of course with all good engineering, in the end you have to make realworld constructs
which actually work... and
that, as they say, is 'where the rubber meets the road' ! :^)
https://www.youtube.com/watch?v=FcJK0t3Qz3Q
>tl;dr
TEST. TEST. TEST.
---
>glossary:
<FK == Forward Kinematics
<IK == Inverse Kinematics
https://en.wikipedia.org/wiki/Inverse_kinematics
>===
-
prose edit
-
add footnote, glossary, hotlink
Edited last time by Chobitsu on 08/21/2024 (Wed) 09:45:17.