I've hit a snag when it comes to this.

Basically I have 3D objects that are organized like a graph of nodes; each node contains a mesh.

For drawing these I traverse the nodes recursively, top to bottom, and set the final transform matrix of each node to that of its parent's full transform multiplied with the node's own local transform. This seems to work like intended and I can have relative transforms for each node.

However, if I set the scale of the topmost node it follows that the relative positions of the child nodes have to change too, or everything will just be scaled in-place, without being repositioned in accordance to each other. Take for example a compound object consisting of two cubes positioned close to each other but with a gap between them. Doubling the scale of this object will indeed make the boxes render twice as large, but since the translation remains the same the gap is now gone and the boxes are overlapping. Not the desired outcome.

I suppose you can just manually transform the matrices of any child nodes by the parents scale matrix when changing the scale, but this just doesn't sound like the best solution to me. Is there another, "standard" way of going about this?

Thanks for any suggestions,

Husbjörn

That's what I'm doing.

Are you saying that such a multiplication should inherently affect the translation of the child matrices as well and that something may be wrong with my matrices (such as multiplication order; I'm currently going with scale * rotation * translation, which seems to be the standard)?

Within your render of the entire mesh, you will have to multiply the subset's matrix by the object's overall matrix.

When constructing any matrix, you need to consider how you perform each task-- the order does matter.

If you have a mesh with multiple subsets you will have a matrix (rotation, scale, and translation) associated with the entire object-- or you should have. This matrix governs the object and its subsets as a "system". When you render the "system" (most of the time called a "frame"), you multiply each subset by the "frame" matrix.

Say for instance you have two boxes, both 2x2x2 and spaced on the x-axis so that the center's are apart by 3 and the center of this "system" is at the origin. This will give a gap (assuming the boxes are axis-aligned) of 1 unit from face to face. If you have a "frame" matrix with a scale of x2, then when you render and multiply each subset by the "frame" matrix, each box will be 4x4x4 in size and one will be centered at location 4,0,0 and the other will be at -4,0,0.

This can get tricky if you don't want the scale to affect the translation. For instance, you have a ball that orbits another object at a specific range and you want to change its scale but not the range. This would involve removing the translation component from the object's matrix m(3,0)==x, m(3,1)==y, and m(3,2)==z and then multiplying that matrix by a scaling matrix and then putting the xyz components back into the matrix. On the other hand, if you want the orbit radius to change with the scale, then leave the xyz components in place.

When constructing any matrix, you need to consider how you perform each task-- the order does matter.

True, I knew that, but I just instinctively assumed you would multiply the child transform by the parent's. Now that I think about it it makes more sense to do it the other way around, and indeed that solved this issue.

Thanks for your assistance :)