[1.16.5] Rotation angles/axis not consistent when rotated

[That_Martin_Guy]

I am rendering a model as part of a tile entity renderer. The model is supposed to be rotated based on the block's facing direction. The kicker is that it's also supposed to be rotated based on a "setting" variable, which can be changed when right clicked.

 

My solution to the problem is rotating around the Y-axis depending on the direction, and rotate either the X or Z axis (depending on the block's direction) by a certain amount per setting. Implementation looks like the following

	public void turnToSetting(Direction direction, TheClockworksTileEntity.Setting setting)
	{
		switch(direction)
		{
			case NORTH:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = setting.rotation;
				break;
			case SOUTH:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = -setting.rotation;
				break;
			case WEST:
				group2.xRot = setting.rotation;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = 0;
				break;
			case EAST:
				group2.xRot = -setting.rotation;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = 0;
				break;
		}
	}

	private float rotationFromDirection(Direction direction)
	{
		double rotation = 0;
		switch(direction)
		{
			case SOUTH:
				rotation = Math.PI;
				break;
			case EAST:
				rotation = Math.PI / 2;
				break;
			case WEST:
				rotation = Math.PI * 3 / 2;
				break;
		}

		return (float) rotation;
	}

In practice this works well when the block is facing north or south, but not when the block is facing east or west. Demonstration here. When observing the way it rotates, it seems like the model's coordinate system has been changed when it was rotated around the Y axis. Therefore I feel like the solution should be to rotate around the Z-axis on the west and east directions. However, this results in the behavior demonstrated here. Code demonstrating that below:

	public void turnToSetting(Direction direction, TheClockworksTileEntity.Setting setting)
	{
		switch(direction)
		{
			case NORTH:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = setting.rotation;
				break;
			case SOUTH:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = -setting.rotation;
				break;
			case WEST:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = setting.rotation;
				break;
			case EAST:
				group2.xRot = 0;
				group2.yRot = rotationFromDirection(direction);
				group2.zRot = -setting.rotation;
				break;
		}
	}

To me this behavior is very similar to rotating on the X-axis. I am confused as to how this is the case.

[SerpentDagger]

What code is processing these angles? To me, it looks like the rotations are processed in the order X, then Y, then Z. This would make it impossible to get the desired skew result in the East/West directions. Here's what I think is happening:

Your model starts with the face pointing to Z+, and the tip to Y+. To get it into a skew for the North/South position, you rotate around Y to account for the flip, then around Z for the skew. All good. To get it into a skew for the East/West, you would have to rotate around Y ± π/2, then around X. Problematic, since the X rotation happens first. If you try to rotate around X first, you just tilt the piece forward or backward, as you've seen. If you try and rotate around Z after, the piece is already pointing face to X±, tip to Y+, and at that point the Z rotation will just tilt it forward/back, as you've seen.

If this is the case, you need to process the rotations in a more useful order, namely with Y first. If you need a more flexible system: I don't think matrix transformations have a specific order*, which would prevent this problem from occurring.

*Not true. They have a specific order. They take effect in the order opposite that of the original multiplications.

Edited October 11, 2021 by SerpentDagger
Correction

[That_Martin_Guy]

The code handling the rotation itself is part of vanilla, the same code that handles rotation of limbs and such. I am not entirely sure this works under the hood, but I'd prefer to not have to create my own rotation system if possible. In that case I'd probably just create a new model that is rotated east/west instead of north/south.

[SerpentDagger]

It looks like the code in ModelRenderer applies rotations X→Y→Z, then translation (Matrix transformations definitely have an order. Sorry, I wasn't thinking). That's why your problem is presenting itself. On the bright side, I think* ModelRenderers can have children which inherit the rotations and translations of the parent. This means that you should be able to have a parent ModelRenderer with the Y rotation, and then the child can have the Z rotation, which is then independent of the block's direction.

*Never used them before, sorry.

[That_Martin_Guy]

Just looked at the code for ModelRenderer, sorry for not doing that earlier. It actually rotates around the z-axis first, if I understand it correctly.

 

   public void translateAndRotate(MatrixStack p_228307_1_) {
      p_228307_1_.translate((double)(this.x / 16.0F), (double)(this.y / 16.0F), (double)(this.z / 16.0F));
      if (this.zRot != 0.0F) {
         p_228307_1_.mulPose(Vector3f.ZP.rotation(this.zRot));
      }

      if (this.yRot != 0.0F) {
         p_228307_1_.mulPose(Vector3f.YP.rotation(this.yRot));
      }

      if (this.xRot != 0.0F) {
         p_228307_1_.mulPose(Vector3f.XP.rotation(this.xRot));
      }

   }

 

I'm not sure how I would go about setting up this parent-child relationship when doing the rotations separately with this knowledge. Not the greatest at this sort of math.

[SerpentDagger]

48 minutes ago, That_Martin_Guy said:

It actually rotates around the z-axis first, if I understand it correctly.

Matrix transformations actually take effect in the opposite order from that of multiplication, which means that it is indeed how I described.

 

53 minutes ago, That_Martin_Guy said:

I'm not sure how I would go about setting up this parent-child relationship when doing the rotations separately with this knowledge. Not the greatest at this sort of math.

I think the way ModelRenderer works means that you could have a parent instance whose yRot is set based on block rotation, and then add your current ModelRenderer with addChild, but only set its zRot. The child should be rendered when the parent's render method is called.