How To Properly Apply Matrix Of Node When Moving To Another Parent Node

[Jonathynlee]

Hello!
I am trying to move a node from one place in the hierarchy to another place in the hierarchy.

I am trying to apply the world matrix to it before moving it, hoping that it would resolve the math properly, Unfortunately, some of the rotations and positions are off.

Steps:

1. Create a new node
2. copy the original node into the new node.
3. Apply the world matrix of the original node.
4. Add the new node to the place in the hierarchy I need it to be.

This process isn't working. Another weird thing is, when I log the world matrix of the original Node and the local matrix, I am getting the same matrix.
Given these nodes are deep within a hierarchy of non-identity matrix'd parents, I don't see how this is possible.

Am I missing something?

I can't share the real code but I will do my best to imitate its functionality here.

(newParentNode)=>{ // parent node is within the hierarchy somewhere   
const originalNode:Node = refToOriginalNode // Original node is within the hierarchy somewhere else   
const newNode:Node = document.createNode().copy(originalNode, resolve);   
newNode.setMatrix(originalNode.getWorldMatrix());   
newParentNode.addChild(newNode);   
}

Any help would be amazing!

Thanks in advanced.
-Jonathyn

p.s.
Images for reference
Before restructure

After restructure

[donmccurdy]

Is this part of the same processing pipeline you mention in #1328? For the reasons mentioned in my comment there — transferring objects from one document to another is frankly error-prone currently and there's a bug fix

A few ideas to perhaps narrow down the problem:

1. Test on the v4.0.0 alpha release (npm install @gltf-transform/core@next)

2. If the document was constructed by cloning or merging objects in from other documents, perhaps try a write/read round-trip to reset everything:

   document = await io.readBinary(await io.writeBinary(document));

Transferring objects from another document is error-prone currently (see #924), and there's a bug fix related to computing world matrices in a cloned document in the v4 alpha release, so I just want to eliminate those as possible causes.

---

Assuming it's not either of those things, this line ...

newNode.setMatrix(originalNode.getWorldMatrix());
newParentNode.addChild(newNode); 

... will only leave the original node in its original location if the new parent node does not have any transform of its own. You could multiply the inverse of the new parent's world matrix into the local matrix of the child, to counteract that.

Or, one of these functions might be helpful to simplify the problem, if you don't mind having the scene hierarchy and transforms changed while keeping visual appearance the same:

• https://gltf-transform.dev/modules/functions/functions/clearNodeParent
• https://gltf-transform.dev/modules/functions/functions/clearNodeTransform
• https://gltf-transform.dev/modules/functions/functions/flatten

[Jonathynlee]

Ill give these a try and get back to you.

Does the gltf-transform lib offer methods for matrix calcs, similar to threejs? I am happy to do them myself if needed but I did notice that when printing the matrix, I was getting a [4x4] +1 matrix. I think that would potentially cause issues with matrix algorithms. Though I supposed there could be something else going on.

I did notice the available types for vec2,3,4 and matrix but they were types only.

Regardless, thanks @donmccurdy!

[donmccurdy]

I was getting a [4x4] +1 matrix.

Do you mean every element in the matrix is '1'? That does sound suspicious...

glTF Transform uses gl-matrix v3 (https://glmatrix.net/) for math internally. The vec2,3,4 and mat3,4 types exported from glTF Transform are compatible with gl-matrix.

If you prefer, you can also use math utilities from three.js, converting to/from glTF Transform types with three.js toArray / fromArray methods on the vector and matrix classes.

[Jonathynlee]

I was getting a [4x4] +1 matrix.

Do you mean every element in the matrix is '1'? That does sound suspicious...

glTF Transform uses gl-matrix v3 (https://glmatrix.net/) for math internally. The vec2,3,4 and mat3,4 types exported from glTF Transform are compatible with gl-matrix.

If you prefer, you can also use math utilities from three.js, converting to/from glTF Transform types with three.js toArray / fromArray methods on the vector and matrix classes.

As suspected, it was just a logging error. Ill will try using the gl-matrix lib.

I know its alpha and prone to bugs, but just a heads up on this one.

With 4.0.0 alpha, I ran into this

I was able to rectify with a simple relative path, though I sure that could have something to do with my compiler. Just wanted to point it out if its helpful to you at all.

readonly accessorParents: Map<Property<import("../properties/property.js").IProperty>, Set<Accessor>>;

Thanks again for all of the help. As of now, the flatten and node transform clearing didn't seem to help. I suspect doing matrix math is the way to go.

This is just an example but essentially there is no guarantee of the new structure as it could be almost anything. It will just include at least all of the nodes from the original in some way or another, visually the Gltf will look exactly the same. No new geometry is added, just informational nodes about hierarchical structure.

[Jonathynlee]

@donmccurdy just wanted to follow up, I think I was able to get 90% there. Seems I have some small issues but transforms are coming across much better now by multiplying the worldMatrix of the child by the inverse world matrix for the new parent.

Additionally, I am no longer cloning the document. I just load it in and modify the original version. Though I didn't see the difference till the change above but it does save some computation time and resource.

Thanks again for all of the help!

Happy to close this if you don't have other comments.

[donmccurdy]

@Jonathynlee glad to hear, and thanks for letting me know about the types error in the v4 alpha! That seems to be caused by microsoft/TypeScript#56087, since reverted in microsoft/TypeScript#57849, so the next v4 alpha release should have the fix. 👍🏻

[Jonathynlee]

For anyone that happens upon this post.

The answer was to multiply the movedNode.getWorldMatrix() multiplied by inv(newParentNode.getWorldMatrix())

import {mat4} from "gl-matrix"
(newParentNode)=>{ // parent node is within the hierarchy somewhere  
let parentInvOfWorldMat:mat4 = newParentNode.getWorldMatrix(); 
glMatrix.mat4.invert(parentInvOfWorldMat,parentInvOfWorldMat);


const originalNode:Node = refToOriginalNode // Original node is within the hierarchy somewhere else   
let newMatrix = originalNode.getWorldMatrix();
mat4.multiply(newMatrix, parentInvOfWorldMat, newMatrix);

const newNode:Node = document.createNode().copy(originalNode, resolve);   
newNode.setMatrix(newMatrix);   
newParentNode.addChild(newNode);   
}

Creds to @donmccurdy for carrying the solution.