So I'm sitting on my couch next to my dog making resource pack magic, like I'm sure you do. And I was curious about the sweet honey that is "mob head textures". So I pop her open and see as expected, they are all parented to "item/skull.json" right? nothing unusual yet. For you fellers looking for a peep, she looks like this...
And I'm thinking, "huh, haven't seen that yet." but it makes sense. and I set my beer down, and say "WELP, what if I plug that "parent": "builtin/entity", business into spawn eggs, maybe I'll get lucky right?" Spawn eggs that look like their mobs might be pretty nifty for a resource pack. So I open up "item/spawnegg.json" and make it look like this...
Yeh, okay. Whatever minecraft. Backwards facing chests. That makes sense. yeah!
Anyway, I'm curious if anyone is knowldegable to what this all means. Why would telling the "model/item/spawnegg" to be parented to "builtin/entity" make them chests? super weird.
So I'm sitting on my couch next to my dog making resource pack magic, like I'm sure you do.
Who doesn't?
To answer your question... according to the documentation on the MC wiki, builtin/entity "load[s] a model from an entity file. As you can not specify the entity, this does not work for all items (only for chests, ender chests, mob heads and banners)."
So I'd imagine it defaults to a chest if there's no available entity to render.
Well I'm not a coder, but I'm guessing that this is a shortcut used by Mojang. Since chests are the only block that's rendered as an entity, it makes more sense for them to have a single hard-coded entity model that could be displayed as a block when that's plugged in. You'll notice that in the vanilla item model it's exactly that: "parent": "builtin/entity".
What's really interesting is that the trapped chest is a child of /item/chest/... meaning that the texture designations are also hard-coded into Minecraft. This makes it impossible to use different textures for the chest as and item and the chest as a block in the world... unless you recreate the item model from scratch. This makes sense as chests also have no block model or blockstate since, again, they're not rendered as blocks but as entities.
As for it being backwards, well, that's just because how Mojang does rotations in the inventory is screwy. It's facing the direction it was modeled... and then turned 180 degrees to be facing the direction it should be. Silly Mojang.
I'd imagine that if they ever do a proper entity models system at least some of this will be cleaned up. Until then, it remains one of those bizarre anomalies in resource packs.
So I'd imagine it defaults to a chest if there's no available entity to render.
It feels odd to me that there's actually a default in the first place. 10/10 minecraft missing texture defaults are just the purple/black checkerboard. Strange that somewhere under the hood. minecraft's got an esle, "use chest entity", up in there. I guess it doesn't make sense to add to the wiki that it defaults to "chest". Just leave a proper search result here. Ahem.... "builtin/entity defaults to a chest."
As for it being backwards, well, that's just because how Mojang does rotations in the inventory is screwy. It's facing the direction it was modeled... and then turned 180 degrees to be facing the direction it should be. Silly Mojang.
I'd imagine that if they ever do a proper entity models system at least some of this will be cleaned up. Until then, it remains one of those bizarre anomalies in resource packs.
I'm not a forum warrior so it's good hearing the world knows the x,y,x rotation business in minecraft is without consistency. I mean you look at the skull.json and it's only rotating in the y axis. What gives? Reminds me of the nightmare that is uv mapping the lit redstone torches on comperators. Etch!
Anyway thanks for solving the science to my curious event folks. cheers. *ting*
So I'm sitting on my couch next to my dog making resource pack magic, like I'm sure you do. And I was curious about the sweet honey that is "mob head textures". So I pop her open and see as expected, they are all parented to "item/skull.json" right? nothing unusual yet. For you fellers looking for a peep, she looks like this...
{
"parent": "builtin/entity",
"display": {
"gui": {
"rotation": [ 30, 225, 0 ],
"translation": [ 0, 3, 0 ],
"scale": [ 1, 1, 1 ]
},
"fixed": {
"rotation": [ 0, 180, 0 ],
"translation": [ 0, 4, 0],
"scale":[ 1, 1, 1 ]
},
"ground": {
"rotation": [ 0, 0, 0 ],
"translation": [ 0, 3, 0 ],
"scale": [ 0.5, 0.5, 0.5 ]
},
"thirdperson_righthand": {
"rotation": [ 45, 45, 0 ],
"translation": [ 0, 3, 0 ],
"scale": [ 0.5, 0.5, 0.5 ]
}
}
}
And I'm thinking, "huh, haven't seen that yet." but it makes sense. and I set my beer down, and say "WELP, what if I plug that "parent": "builtin/entity", business into spawn eggs, maybe I'll get lucky right?" Spawn eggs that look like their mobs might be pretty nifty for a resource pack. So I open up "item/spawnegg.json" and make it look like this...
{
"parent": "item/skull"
}
Probably gonna error, but worth it.
Run the game.
Open up my inventory and...
image
Yeh, okay. Whatever minecraft. Backwards facing chests. That makes sense. yeah!
Anyway, I'm curious if anyone is knowldegable to what this all means. Why would telling the "model/item/spawnegg" to be parented to "builtin/entity" make them chests? super weird.
Who doesn't?
To answer your question... according to the documentation on the MC wiki, builtin/entity "load[s] a model from an entity file. As you can not specify the entity, this does not work for all items (only for chests, ender chests, mob heads and banners)."
So I'd imagine it defaults to a chest if there's no available entity to render.
Well I'm not a coder, but I'm guessing that this is a shortcut used by Mojang. Since chests are the only block that's rendered as an entity, it makes more sense for them to have a single hard-coded entity model that could be displayed as a block when that's plugged in. You'll notice that in the vanilla item model it's exactly that: "parent": "builtin/entity".
What's really interesting is that the trapped chest is a child of /item/chest/... meaning that the texture designations are also hard-coded into Minecraft. This makes it impossible to use different textures for the chest as and item and the chest as a block in the world... unless you recreate the item model from scratch. This makes sense as chests also have no block model or blockstate since, again, they're not rendered as blocks but as entities.
As for it being backwards, well, that's just because how Mojang does rotations in the inventory is screwy. It's facing the direction it was modeled... and then turned 180 degrees to be facing the direction it should be. Silly Mojang.
I'd imagine that if they ever do a proper entity models system at least some of this will be cleaned up. Until then, it remains one of those bizarre anomalies in resource packs.
It feels odd to me that there's actually a default in the first place. 10/10 minecraft missing texture defaults are just the purple/black checkerboard. Strange that somewhere under the hood. minecraft's got an esle, "use chest entity", up in there. I guess it doesn't make sense to add to the wiki that it defaults to "chest". Just leave a proper search result here. Ahem.... "builtin/entity defaults to a chest."
I'm not a forum warrior so it's good hearing the world knows the x,y,x rotation business in minecraft is without consistency. I mean you look at the skull.json and it's only rotating in the y axis. What gives? Reminds me of the nightmare that is uv mapping the lit redstone torches on comperators. Etch!
Anyway thanks for solving the science to my curious event folks. cheers. *ting*