Minecraft
  1. Minecraft
  2. MC-107581

Animation of totem is affected by "fixed" display setting rotation (and is inverted)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: Minecraft 16w39a, Minecraft 16w43a
    • Security Level: Minecraft - Public (Viewable by everyone)
    • Labels:
      None
    • Confirmation Status:
      Unconfirmed

      Description

      As the title says, the animation of the "Totem of Undying" (once used) appears to be affected by the "fixed" display setting, and for the main swoop, is the reverse of the way the model displays whilst in an item frame. This works for models generated from the texture, and models that are the same both sides, but for models that are made to face a certain way, it means that for the main part of the animation, only the back is visible. Is there any way this could be reversed?

      I've attached a simple block model with different wool on each face to verify that the animation is indeed the reverse of the display in an item frame.

      EDIT: I've made some gifs to demonstrate what I mean. (I can't legally attach the model, as it's from PureBDcraft)

      So this is with "y" rotation in the "fixed" display setting as zero:
      http://i.imgur.com/cfN93UZ.png

      In this case, the animation mainly shows the back of the model:
      https://gyazo.com/b6f412affae23d98260c356af138712e

      Whereas in this case, "y" rotation is set to 180:
      http://i.imgur.com/jEnSOcq.png

      And then the animation shows the face: https://gyazo.com/fe187d2603d649922deed409d41a9ed8

      As you can see, the second animation is much better visually, but it has a bad effect on the item frame display.

      Is there any way this could be fixed?

        Activity

        Hide
        [Mojang] Jeb (Jens Bergensten) added a comment -

        Ben: I think the problem here is that the model itself is inverted, right? If you just modelled it to face the other way, the 'fixed' transform shouldn't need a rotation at all, or am I missing something?

        Show
        [Mojang] Jeb (Jens Bergensten) added a comment - Ben: I think the problem here is that the model itself is inverted, right? If you just modelled it to face the other way, the 'fixed' transform shouldn't need a rotation at all, or am I missing something?
        Hide
        Ben Durrant added a comment -

        I'm afraid that wouldn't work. The point is, the "fixed" display setting affects both the display when in an item frame and during the animation, and in effect appears to be inverted, as irrespective of which way the model truly faces, if the "fixed" display rotation is set to one value, for example 0, the item frame shows one side (http://i.imgur.com/cfN93UZ.png), and the main segment of the animation shows the opposite (https://gyazo.com/b6f412affae23d98260c356af138712e). If nothing else, only the "fixed" display rotation is modified to show the inverse, so in this case 180, the item frame shows the side that was shown during the animation the first time (http://i.imgur.com/jEnSOcq.png), and the animation shows the side that was shown in the item frame (https://gyazo.com/fe187d2603d649922deed409d41a9ed8). Again, this happens regardless of the model's original orientation. This is testable using the resourcepack I've attached, which uses a different colour wool for each face of a simple cube. When in an item frame, the cube shows one face, but when the animation is triggered, the main swoop shows the complete opposite side, as evidenced when the item is dropped, to make all sides visible.

        Show
        Ben Durrant added a comment - I'm afraid that wouldn't work. The point is, the "fixed" display setting affects both the display when in an item frame and during the animation, and in effect appears to be inverted, as irrespective of which way the model truly faces, if the "fixed" display rotation is set to one value, for example 0, the item frame shows one side ( http://i.imgur.com/cfN93UZ.png ), and the main segment of the animation shows the opposite ( https://gyazo.com/b6f412affae23d98260c356af138712e ). If nothing else, only the "fixed" display rotation is modified to show the inverse, so in this case 180, the item frame shows the side that was shown during the animation the first time ( http://i.imgur.com/jEnSOcq.png ), and the animation shows the side that was shown in the item frame ( https://gyazo.com/fe187d2603d649922deed409d41a9ed8 ). Again, this happens regardless of the model's original orientation. This is testable using the resourcepack I've attached, which uses a different colour wool for each face of a simple cube. When in an item frame, the cube shows one face, but when the animation is triggered, the main swoop shows the complete opposite side, as evidenced when the item is dropped, to make all sides visible.
        Hide
        [Mojang] Jeb (Jens Bergensten) added a comment -

        Sorry I made you write that long response, I realized my mistake while at a meeting =)

        In the end I discovered that the problem was not for the token itself, but rather in the item frame renderer. The item frame has a hard-coded 180 degree rotation on all non-3d item models. This was easily fixed by remove the hard-coded rotation and replacing it with a json definition for 'fixed' transform in "generated.json". There's a similar bug regarding mob skulls.

        I've fixed this but it will not be in this week's snapshot because I was too late to commit to the branch.

        Show
        [Mojang] Jeb (Jens Bergensten) added a comment - Sorry I made you write that long response, I realized my mistake while at a meeting =) In the end I discovered that the problem was not for the token itself, but rather in the item frame renderer. The item frame has a hard-coded 180 degree rotation on all non-3d item models. This was easily fixed by remove the hard-coded rotation and replacing it with a json definition for 'fixed' transform in "generated.json". There's a similar bug regarding mob skulls. I've fixed this but it will not be in this week's snapshot because I was too late to commit to the branch.
        Hide
        [Mojang] Jeb (Jens Bergensten) added a comment -

        Also: I discovered that the item which is used to activate the animation is ignored. The game is supposed to be able to play the totem animation with any kind of item, but there was still a hard-coded totem item instance in the renderer, which I fixed thanks to this bug report.

        Show
        [Mojang] Jeb (Jens Bergensten) added a comment - Also: I discovered that the item which is used to activate the animation is ignored. The game is supposed to be able to play the totem animation with any kind of item, but there was still a hard-coded totem item instance in the renderer, which I fixed thanks to this bug report.
        Hide
        Ben Durrant added a comment -

        Glad that's sorted out then No problem about the paragraph, I'm just glad it's fixed

        Show
        Ben Durrant added a comment - Glad that's sorted out then No problem about the paragraph, I'm just glad it's fixed

          People

          • Assignee:
            [Mojang] Jeb (Jens Bergensten)
            Reporter:
            Ben Durrant
          • Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: