[1.14.4] Syncing rendered held item movement with head?

[JayZX535]

Hello,

 

I have a dog entity that can carry food items in its mouth (much like foxes).  I'm trying to make its held item actually render there as it eats, but I'm having a little trouble getting it to actually work properly.  When the dog is standing still it works fine.

 

 

However, when the dog moves its head to look at the player, tilting it in a certain way, it goes all askew for a bit until the dog fully stops moving.

I've been looking at the fox's head movement in particular, but that class has a lot of variables and functions that still have the default names, which is giving me a hard time tracing what they're used for.  It has a specific parameter to account for Z Axis tilt, but it's hard to figure out what conditions are actually causing it to be used and for what.  My dog entities also have a lot of potential poses, so the more universalized my solution can be, the better.  Right now the code I have is this, which works alright while the dog is perfectly still but when it looks around (particularly when turning its head at an angle to the player), the rendered item does that weird tilting.

 

@SuppressWarnings("deprecation")
@OnlyIn(Dist.CLIENT)
public class WCWolfHeldItemLayer extends LayerRenderer<WCWolfEntity, WCWolfModel<WCWolfEntity>> {
	
   private final ItemRenderer itemRenderer = Minecraft.getInstance().getItemRenderer();
   public WCWolfHeldItemLayer(IEntityRenderer<WCWolfEntity, WCWolfModel<WCWolfEntity>> wcwolf) {
	   super(wcwolf);
   }

   public void render(WCWolfEntity entityIn, float limbSwing, float limbSwingAmount, float partialTick, float ageInTicks, float netHeadYaw, float headPitch, float scale) {
      ItemStack itemstack = entityIn.getStackInSlot(entityIn.getHeldSlotID());
      if (!itemstack.isEmpty()) {
    	  GlStateManager.pushMatrix();
    	  float rotMultiplier = (float)Math.PI / 180F;
    	  GlStateManager.translatef((this.getEntityModel().getHead().rotationPointX / 16F), (this.getEntityModel().getHead().rotationPointY / 16F), (this.getEntityModel().getHead().rotationPointZ / 16F));
          float calcHeadPitch = this.getEntityModel().getHead().rotateAngleX / rotMultiplier;
          GlStateManager.rotatef(calcHeadPitch, 1.0F, 0.0F, 0.0F);
          float calcHeadYaw = this.getEntityModel().getHead().rotateAngleY / rotMultiplier;
          GlStateManager.rotatef(calcHeadYaw, 0.0F, 1.0F, 0.0F);
          float calcHeadTilt = this.getEntityModel().getHead().rotateAngleZ / rotMultiplier;
          GlStateManager.rotatef(calcHeadTilt, 0.0F, 0.0F, 1.0F);
          GlStateManager.translatef(0.0F, 0.1F , -0.3F);
          GlStateManager.rotatef(-90.0F, 1.0F, 0.0F, 0.0F);
          GlStateManager.translatef(0.001F, 0.0F, 0.0F );
          this.itemRenderer.renderItem(itemstack, entityIn, TransformType.GROUND, false);
          GlStateManager.popMatrix();
      }
   }

   public boolean shouldCombineTextures() {
      return false;
   }
}

 

Stuff like the Math.PI calculation comes from what I've observed in other entity classes and it seems to be working at least in part?  My current method here attempts to get the tilt value directly from the head itself.  But that's still causing problems.  So I'm wondering if maybe I'm getting the rotation value wrong?  The value used in the model class seems to be handled differently than the rotation value here.  Putting them in one-for-one causes negligible movement on the item while the head moves a lot.  In the model class, the inputs like netHeadYaw and headPitch seem to be divided by that Math.PI / 180F value, whereas in the fox held item class it seemed like those values were inputted directly to the held item.  There's not a visible tilt value though, not that I've found, and I have some custom animations defined within the model class that I need to account for.  That's why I want to get the value directly from the head rotation if possible-- otherwise I'll have to figure out a way of patterning all the checks I do in the model class somehow, and I really don't want to have to have both classes running the same checks for pose and such if I can help it.

 

Anyone else have an idea of what I could try here?  Thanks.

[Draco18s]

(Note that Y and Z are swapped in Minecraft)

Now check your code again.

[JayZX535]

Shoot, that explains some things, hah-- thanks.  Went ahead and swapped them, but it's still being a little funky...

Updated code:

@SuppressWarnings("deprecation")
@OnlyIn(Dist.CLIENT)
public class WCWolfHeldItemLayer extends LayerRenderer<WCWolfEntity, WCWolfModel<WCWolfEntity>> {
	
   private final ItemRenderer itemRenderer = Minecraft.getInstance().getItemRenderer();
   public WCWolfHeldItemLayer(IEntityRenderer<WCWolfEntity, WCWolfModel<WCWolfEntity>> wcwolf) {
	   super(wcwolf);
   }

   public void render(WCWolfEntity entityIn, float limbSwing, float limbSwingAmount, float partialTick, float ageInTicks, float netHeadYaw, float headPitch, float scale) {
      ItemStack itemstack = entityIn.getStackInSlot(entityIn.getHeldSlotID());
      if (!itemstack.isEmpty()) {
    	  GlStateManager.pushMatrix();
    	  float rotMultiplier = (float)Math.PI / 180F;
    	  GlStateManager.translatef((this.getEntityModel().getHead().rotationPointX / 16F), (this.getEntityModel().getHead().rotationPointY / 16F), (this.getEntityModel().getHead().rotationPointZ / 16F));
          float calcHeadPitch = this.getEntityModel().getHead().rotateAngleZ / rotMultiplier;
          GlStateManager.rotatef(calcHeadPitch, 1.0F, 0.0F, 0.0F);
          float calcHeadYaw = this.getEntityModel().getHead().rotateAngleY / rotMultiplier;
          GlStateManager.rotatef(calcHeadYaw, 0.0F, 1.0F, 0.0F);
          float calcHeadTilt = this.getEntityModel().getHead().rotateAngleX / rotMultiplier;
          GlStateManager.rotatef(calcHeadTilt, 0.0F, 0.0F, 1.0F);
          GlStateManager.translatef(0.001F, 0.1F, -0.3F);
          GlStateManager.rotatef(-90.0F, 1.0F, 0.0F, 0.0F);
          this.itemRenderer.renderItem(itemstack, entityIn, TransformType.GROUND, false);
          GlStateManager.popMatrix();
      }
   }

   public boolean shouldCombineTextures() {
      return false;
   }
}

 

Edited April 1, 2020 by JayZX535

[Draco18s]

I'm not going to be able to help directly, but I'm pretty sure you're going to need multiple translations and rotations, as first you need it to lay flat, then position it at the dog's mouth, then offset to deal with rotating based on the dog's head's movements (the pivot point of the head and the item aren't the same!) and translate back.

[JayZX535]

Hmmm.  That's sort of what I was trying to do?  I was attempting to compensate with the different pivot point of the head and item by setting the item to the head's rotation point, rotating it, and then positioning it at the mouth from there.  Is the pivot point of the item the same as its origin?  If not that could be screwing it up...

Here's a more detailed breakdown of what this is (or is supposed to) do...

 

float rotMultiplier = (float)Math.PI / 180F;
GlStateManager.translatef((this.getEntityModel().getHead().rotationPointX / 16F), (this.getEntityModel().getHead().rotationPointY / 16F), (this.getEntityModel().getHead().rotationPointZ / 16F));     

Sets a standardized rotation amount (and I'm not sure if this is correct, but it's the inverse of the calculations used to set the head animations for the entity model, and it looks like the item rotations should take the actual amounts-- so this should reverse it?), and then sets the item to the rotation point of the head.

 

float calcHeadPitch = this.getEntityModel().getHead().rotateAngleZ / rotMultiplier;
GlStateManager.rotatef(calcHeadPitch, 1.0F, 0.0F, 0.0F);
float calcHeadYaw = this.getEntityModel().getHead().rotateAngleY / rotMultiplier;
GlStateManager.rotatef(calcHeadYaw, 0.0F, 1.0F, 0.0F);
float calcHeadTilt = this.getEntityModel().getHead().rotateAngleX / rotMultiplier;
GlStateManager.rotatef(calcHeadTilt, 0.0F, 0.0F, 1.0F);        

Gets the X, Y, and Z rotation values from the head and applies them to the item.

 

GlStateManager.translatef(0.001F, 0.1F, -0.3F);
GlStateManager.rotatef(-90.0F, 1.0F, 0.0F, 0.0F);
this.itemRenderer.renderItem(itemstack, entityIn, TransformType.GROUND, false);   

Translates the item to where it should be in the dog's mouth, rotates it 90 degrees (to make it lay flat), and then renders it.

 

Note, the TransformType.GROUND does throw a deprecation error, which leads me to net.minecraftforge.client.extensions.IForgeBakedModel.handlePerspective(TransformType cameraTransformType) instead, but I'm trying to figure out how to actually use that?  I'm not sure if that's what's causing the issue or not but it's worth noting...

[TheGreyGhost]

Hi Jay

 

You might find this link useful, although it sounds like you've got a good grasp of the concepts already

http://greyminecraftcoder.blogspot.com/2020/03/minecraft-model-basics-rotation-1144.html

 

Something I've found extremely useful while debugging model rotations, translations, and scales is to add in-game tweakable parameters, i.e. typing a command

/mbedebug setheadrotation 2 53 6

and seeing what effect it has on the model without having to recompile.

See mbe80 in here for an example

https://github.com/TheGreyGhost/MinecraftByExample

 

There are lots of traps when rotating and translating and I can never figure it out on paper, I find it easier to get 80% of the way there based on the theory and then get the rest of the way by trial and error.

 

Things that have tripped me up:

* order of transformation (translation, rotation) is extremely important and (at least for me) not intuitive.  Even when I try to follow the theoretical rules I still usually stuff it up

* rotation around an arbitrary point (as you already said) is translate, rotate, translate, but not necessarily in the order/direction you expect

* model space vs world space -> your rotations and translations may be around a different axis to what you expect, or around a different origin, and translation may be in the opposite or even in an oblique direction

Generally the answer has been:

keep model-space and world space transformations separate

if vanilla forces you to apply one at a time that you don't want to, you need to transform back from world to model, do your desired transformation, then transform from model back to world again.

take baby steps

use interactive in-game parameter tweaking of some kind (eg the mbe80 I mentioned above)

 

-TGG

 

 

 

 

 

 

 

[JayZX535]

Hey again TGG,

 

Thank you so much for the advice (and validation that this is heckin confusing haha).  After a lot of fiddling, I was finally able to figure out the string of issues that was causing problems.  In case anyone else ends up finding this later in search of help, here's what I ended up doing to solve my issues.

 

Firstly, as it turns out you can't just use the yaw of the head, since that doesn't account for the model rotation.  The headNetYaw variable calculates that difference out, so unless you mirror that rotation, you're better off using the variable itself.  So I switched back to that method.

 

To get around the issue of having multiple poses, some with fixed head position and some with dynamic, I built in some methods to the model class to check the entity's pose and return the proper value for the head position.  I designed them to return either the raw version of the variable (needed for the item rotation), or the calculated one (needed for the rotation of the actual model parts), which allowed me to ensure that the proper result would be returned in both cases.  This avoids the issue of having to write up a checker code within the item renderer itself, and that way I only have to worry about changing one set of code if I make any tweaks.

 

Lastly, I finally figured out the biggest stumper, which was the fact that the rotation was still crooked even with the synchronized method.  I tested each one individually by forcibly returning zero on the two I wasn't using, and determined that individually, they were all doing what they should be.  However, they were messing up when combined.  As it turned out, I had the order of rotation different on the item renderer (pitch > yaw > tilt) than on the entity model (tilt > yaw > pitch).  Changing the rotations on the item class to match the order of the ones on the entity model solved the problem.  So it did indeed come down to the order of transformation in the end.

 

Definitely one of the tripper problems I've dealt with, but I'm happy to report I finally have it solved.  Thank you guys again for your help!

[Draco18s]

Glad you figured it out. :)