now I know your first thought is going to be rotation matrices, but take a moment to think about how they're applied...
I'm wondering if there isn't something more efficient, or if there really needs to be that many operations per bone and vertex.

I'm looking for the smallest data structure, as well as how to convert to and from it, with application as well.
all of which hopefully housing less than 16 operations per bone.

I'm currently trying euler angles which are believed to have fewer operations for building the influence result, though I'm told otherwise.
(please don't bring up gimbal lock as it's not even a factor, since I'm not applying them 1 axis at a time)
but I'm currently having a problem finding an accurate conversion algorithm from quaternions...
pretty much every algorithm uses asin, limiting the offending axis by 90° max movement.
if not that, then the orientation is improper, XZY or YZX for example, and flipping them around illogically yields improper results...

proper orientation is in OpenGL terms, related to your monitor:
X - width
Y - height
Z - depth

now in rotation, this applies as such with a plane facing towards you:
X - pitch
Y - yaw
Z - roll

there's other terms referring to attitude, heading, and bank, but I don't understand the relations...

could someone help clear up these conundrums, or perhaps provide code please :)
comments appreciated as I would like to learn what each line does :)

many thanks, and credit to you in my project. :)

also, please don't mention 3rd party packages... I'm doing my own stuff and would prefer to avoid locks.
I don't care about reinventing the wheel again

Dani AI

Generated

Quick summary tied to the thread: is right to look past full 4x4 matrices if storage or per-bone bandwidth matters; ’s Rodrigues hint is useful for single-axis/axis-angle work, but for compact, robust animation the common choices are (a) a normalized quaternion plus a translation (4 + 3 floats = 7 floats per bone) or (b) a dual quaternion (8 floats) when you need compact rotation+translation blending without matrix-artifacts. (en.wikipedia.org)

Use quaternions internally and avoid converting to Euler for math (keep Euler only for UI/authoring). To apply a bone rotation directly to a vertex without building a matrix, rotate the vector by the quaternion using the cross-product form (faster than two full quaternion multiplications):

vec3 rotateByQuat(vec3 v, quat q) {
  vec3 t = 2.0 * cross(q.xyz, v);
  return v + q.w * t + cross(q.xyz, t);
}

This is the common optimized vector-rotation form. (en.wikipedia.org)

If you need GPU/vertex efficiency at scale, keep bones as quat+translation, convert each bone once per frame to a 3x3/4x4 matrix (cheap per-bone) and upload matrices for fast mat4*vec4 skinning in the shader — per-vertex matrix multiplies are usually faster on GPUs than doing many cross-products per influence on the CPU. When converting quaternions ↔ Euler for display, use atan2-based formulas (not raw asin alone) and always clamp the asin input to [-1,1] to avoid numerical issues and the apparent "90° limit" from naive arcsin uses. (en.wikipedia.org)

If minimizing storage and getting correct blends is the priority, use dual-quaternion skinning (8 floats, good blending, requires normalization after blending). If minimizing per-vertex ops is the priority and you have a GPU, prefer per-bone matrix precomputation + GPU skinning. Always normalize quaternions after any blending or lerp/nlerp operations to keep behavior stable. (en.wikipedia.org)

Recommended Answers

All 3 Replies

hey there grib, it's been a while =)
I'm on discord if you've wondered, pm me if you'd like an invite :)

anyways, interesting read, though I can't really understand math...
(took pre-algebra 3 times because I was too overwhelmed by the amount of homework to pass the class)
^ I understood the work just fine, but the amount was just overwhelming... it never got finished in time...
I barely took algebra 1 in 12th grade and passed...
anyways, if you could translate that to very raw code (any easy language), it would help out very much :)

nice find btw :)
even skimmed across the euler version, which might clear things up a bit there as well.
big thanks!

oh good, lost my edit... forgot this forum has a time limit >_<

so I did some googling and found the formula was susceptible to gimbal lock...

I do have a code which applies eulers to vectors using matrix math to avoid gimbal lock,
but one of the reasons for this question was to figure out it I could do something with less operations...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.