[NOESIS] Titan Quest

[MrAdults]

bone1 bone2 bone3 bone1 bone2 bone3

That one.

[Demonsangel]

I'm oblivious as what I'm supposed to be doing with the animations.
I basically read the positions and angles and put them into a mat43.

create the animation: NoeAnim("walk", self.bones, numFrames, frameMat, FPS)

and it comes out like this

So I figured I was doing my Mat43's wrong and started multiplying them, the first frame I multiplied with the matrix of the bones. The following frames I multiplied with the previous frame.
First frame came out like this:


Changing the angles doesn't seem to actually effect anything significant atm.

Don't know if it'll help but here's the raw position info for the first frames

Code: Select all

(0.0, 0.0, 0.0)
(0.14962191879749298, -0.00534363929182291, -2.316098424159918e-09)
(-9.8387658908905e-08, 1.387635872873716e-08, 3.293631711223828e-14)
(5.372397637870563e-08, -6.738577251752531e-09, -1.0794913140460549e-13)
(1.9564912179248495e-07, 2.4569342116365078e-08, 4.960473763519768e-13)
(-4.312672530204509e-08, -5.385255619216878e-08, 3.333727066102965e-13)
(3.496630895938324e-08, 6.641565519771575e-09, 2.379064056867719e-09)
(2.7545311809262785e-08, 3.905058054698429e-09, 3.860357034035644e-10)
(0.03554629907011986, 0.08017075806856155, -7.877627439256685e-08)
(-1.8355015640736383e-07, 2.4650452346008933e-08, 1.937892051273593e-07)
(2.1736765276614278e-08, 3.062447007096125e-08, -1.6018371695736278e-07)
(0.035993222147226334, 0.07500851899385452, -7.446584238124387e-09)
(-4.413537091352282e-09, -1.9153316088704742e-07, 2.1141575246019784e-07)
(5.3303590874520523e-08, -1.1442565117647518e-08, -6.808340202724139e-08)
(-5.941072522830382e-09, -7.996898254702955e-09, -2.3549111105580778e-08)
(1.481507894141032e-07, -1.1377987618743646e-07, -1.3762331718680798e-07)
(1.0442823139555912e-07, -7.164797466430173e-08, -3.856521005318747e-12)
(1.521200516663157e-07, -1.0614267154096524e-07, -1.4187689600930753e-07)
(-6.125354445885023e-08, -3.9537052742844025e-08, 1.1431549751250714e-07)
(-3.084172917056094e-08, -3.3520187514568534e-08, 6.005618047311145e-08)
(2.682209014892578e-07, -1.9424078345764428e-07, 1.7329865542592415e-08)
(8.940696716308594e-08, -2.754945569449774e-07, 8.612432367272049e-08)
(9.019845492730383e-08, 8.471759116446265e-08, 9.43741866876735e-08)
(4.3218520318077935e-08, -3.6637638345382584e-07, 7.605304119806533e-08)

[Tamschi]

The animations should transform the existing bones for each frame.

To play an animation, a program has to do the following:

1. Transform all vertices with the inverse bone matrix so the bones all equal the unit vector. (Noesis already does this, judging by the screenshots.)

The mesh resulting from step 1 is constant, so this is usually the one uploaded to the graphics card.

2. Transform all vertices with the transformed bone matrix to get the skinned mesh in object space.

In this case:

boneTransform = transformationFromAnimation x untransformedBone.

boneToObjectSpaceTransform = parentBoneToObjectSpaceTransform x boneTransform

vertexInObjectSpace = sum(boneWeight * boneToObjectSpaceTransform x vertexFromStep1)



It's possible that a boneToScreenSpaceTransform (= objectToScreenSpaceTransform x boneToObjectSpaceTransform) is used, as this is a constant for each rendered frame.
Titan Quest seperates them though, at least in the uniform parameters. Step 3 would be vertexInScreenSpace = objectToScreenSpaceTransform x vertexInObjectSpace in this case.

There's a similar calculation for the vertex in world space, wich is used for lighting, as well as for the normals. I'm pretty sure the normal calculation can be combined with the position calculation if matrices are used, I don't know how TQ does it though. (I can't read shader assembly.)


Anyway, what's missing are these calculations from step 2:

boneTransform = transformationFromAnimation x untransformedBone.

boneToObjectSpaceTransform = parentBoneToObjectSpaceTransform x boneTransform

I couldn't find the documentation, but this is extremely common, so it's possible that it's supported by Noesis.

[MrAdults]

Looks like the animation matrices need to be multiplied against the bone matrix or some kind of base yeah, but Noesis still wants animation matrices in parent-relative space. So most likely you want correctedBoneMatrix * inverseCorrectedParentMatrix. As to how to get correctedBoneMatrix, that's up to the peculiarities of TQ. I know nothing about its data so I can't really help out there. The first shot is what makes me say those matrices need to be based on something else, they don't look like they're in the same scale as the vertices/base skeleton, and animation matrices are already part of the hierarchical transform Noesis-side during rendering so you should not feed anim matrices to Noesis in model space. Bone matrices should be in model space though, as I mentioned a little while ago in this thread, that's an intentional difference between model bone matrices and animation bone matrices.

[Demonsangel]

Yeah, this is chinese to me. I can't even create an animation that keeps pose mode/doesn't move or rotate the bones.

Also, when exporting to .dae to 3ds max (second screenshot) i noticed the rootbone was scaled to 39% but I didn't actually scale anything?

[MrAdults]

A lot of COLLADA importers automatically scale on import. Some of them you can instruct not to do so, some of them you can't. I've become kind of frustrated with the whole situation there and started using FBX in place of COLLADA, but then you have another set of issues to deal with. Hopefully the upcoming semi-rewrite of the FBX SDK and resulting semi-update of the FBX standard will result in FBX support sucking significantly less everywhere. (but my experience with Autodesk sadly leads me to believe it will lead to FBX support sucking significantly more everywhere, for another 3-4 years until they finally manage to make it almost work like it should, shortly before deciding on another major architectural change that destroys everything all over again)

[Demonsangel]

I thought about that, but I noticed, like in the second screenshot how all the mesh parts are so seperated. When I imported it into 3ds max it looked the same as in the screenshot and when I scaled them back to 100% they just need a bit of rotation/positioning and it was okish.

So I'm not sure if it's me doing anything wrong or if it's the .dae importer, but i'll have a look for the scaling option if it's there.

[Tamschi]

I've got the complete animation frame format now (all values in bone space and not premultiplied):

Code: Select all

Vec3    Offset (xyz)
Vec4    Rotation1 (xyzw Quaternion)
Vec3    Scale (xyz)
Vec4    Rotation2 (xyzw Quaternion)

[Demonsangel]

Thanks, but I'm not experienced enough with bones/animations. Having a hard time figuring it out.
Same for another format I'm working on, I have all the data, I just don't know what to add/mul/sub/div with what.

[Tamschi]

Here's the link to the site that made me finally understand quaternions today: http://iquilezles.org/www/articles/quat ... rnions.htm

The data from the animations is in joint space as far as I can tell and not parent-relative, so you have transform (multiply) it with the bone matrix from the mesh to make it parent-relative in the end.

The multiplication order depends on the python environment and matrix alignment, so I don't know whether it's right-to-left or left-to-right.

The frames are independend, so don't multiply them with previous ones.

As MrAdults already said, the bone matrix construction depends on the game, so you'll have to experiment with the order you apply the transformations from the animation frame in.

[Demonsangel]

I was already calculating the animations vs the bone matrices, but at a certain point my imagination just runs out of combinations to try.

But I'm guessing it's because I don't know how to correctly use the NoeAnim().
I checked the data for the root bone and it's first child. The matrix for the root stayed the same while for the child there was only a minor change on the x-offset. However the result was the bone being totally rotated around every axis. (Not even child-parent multiplied)