Ok, the skinning equation for each vertex in a DAE is as follows (from Khronos documentation):
And I understand that. However, I’d like to further simplify this. I’d like to “standardize” my joint transformation matrices (JMi), and pre-apply certain scaling-rotation-translation aspects to the vertices.
I know how to get the vertices (that’s easy). Here’s what I don’t know. For example, let’s say I’d like to scale my mesh by 100x. I can also easily decompose my transformation matrices into Scale_Vector, Rotation_Quaternion, & Translation_Vector easy enough.
So, can I do this:
- Multiply each mesh vertex X 100, putting them back into the DAE.
- Get all the joint transformation matrices.
- Decompose them.
- Take the Scale_Vectors and divide the X,Y,Z by 100.
- Re-compose the transformation matrices with the new Scale_Vectors.
- Then put those matrices back into the DAE.
I’d also possibly like to do that with rotation and/or translation constants as well.
(Just as an FYI, I can also get from quaternions to Euler angles, and vice-versa, just fine.)
COLLADA Document Object Model (DOM) / Code / [r941] /trunk/rt/src/CrtController.cpp is a place to start for example code, and it does preprocess data into matrices. It sounds like your goal is to “translate” the DAE file into a new file, in which case you might replace any non-matrix transform elements with matrix transforms.
Hello Mick_P,
Yes, you are correct in saying that I’ll be writing a new DAE file from the original. However, it’s not really a problem with transforming non-matrix elements into a matrix. I know how to do that just fine. Also, with respect to the DAE files with which I’m dealing, all the transformations are already in matrix form.
My primary problem is “standardizing” the skinning matrices associated with joints, such that they’re the same for two separate DAE files. I’m getting DAE files for which the positions are scaled vastly differently. Also, in many cases, the positions of one file are rotated by 90° with respect to the other.
So, I’d like to build/write a program that transforms one of these files such that the skinning joint matrices match the scaling and rotation of the other.
I’ve got no problems going through the position vertices and re-scaling and/or rotating them.
And, I’ve got no problems taking a transformation matrix and applying additional scaling and/or rotation to it.
I’m just not sure of how everything is put together in these DAE files, especially with respect to skinning.
I’m still sorting a few other things, but I’ll be doing some trials very soon. If I figure it all out, I’ll come back here and post my results.
Hello KyleFlynn
As I recall the <asset> element should include coordinate-system and scale-factor information. Correctly managing scale across files can be difficult really. I think you want to map the matrices into certain basis vectors, which is same as the coordinate-system convention.
Ok, I figured out one thing. It’s the “inverse bind-pose matrix for each joint” (IBMi) that I’m talking about, and not the “transformation matrix of each joint” (JMi). It’s those IBMi matrices I’m trying to simplify/synchronize. I guess the JMi is a matrix that’s calculated during an animation, and not actually in the DAE file. I’m talking about those IBMi matrices that are actually in the DAE files.
Regarding the tag, I’m not talking about that at all. I always leave that as <up_axis>Z_UP</up_axis>. I’m not sure it matters if we just completely delete the section.
Mostly what I’m talking about is in the <library_controllers><controller…> section, and also in the <library_geometries><geometry…> section. The joint matrices (IBMi) always seem to be in the <controller…> section, and our position vertices are always in the <geometry…> section.
Again, I want to understand how to standardize and transform those IBMi matrices (adjusting the positions in the <geometry…> section as needed to accommodate these changes to the IBMi matrices.
I’ll eventually figure it out. I just thought I’d see if others had familiarity with this. Someone certainly does, as programs like Blender, Maya, etc. get written by someone. I guess they’re just not participating in these forums.
I haven’t looked at this in a very long time, but in the spec I see INV_BIND_MATRIX as an input. I think these are for defining the “bind pose”.