I have a multipart model for a block with a lot of states (maybe too many, but that's another issue). In it, some of the block state properties needs to be able to change the texture of the model. Ideally I'd add conditions in the multipart model definition to set the texture appropriately, but it seems like this feature isn't available.

 

Since I'd prefer not to make a hundred or so new model JSONs just to do what I want (since that would increase load time and make things tough for resource pack makers), is there a good workaround for what I'm trying to achieve?

Edited November 15, 20195 yr by imacatlolol

If I understand you right, I think I have a similar issue at the moment ^^

Bumping, if that's alright.

One of my ideas for a solution would be to assign it a dedicated texture map that contains all of the variants, then somehow offset the UVs in a custom baked model. Not sure how to go about offsetting things like that, if that's even the best idea.

Edited November 15, 20195 yr by imacatlolol
Clarity

11 hours ago, imacatlolol said:

One of my ideas for a solution would be to assign it a dedicated texture map that contains all of the variants, then somehow offset the UVs in a custom baked model. Not sure how to go about offsetting things like that, if that's even the best idea.

I recommend against making your own texture map. Also, baked models I’ve always point into the block texture map, you would have to stitch your own texture map into the block texture map. I think that the best thing to do is to make the json files. Also, metadata (blockstate files) should be kept separate from data (model files).

1 hour ago, Cadiboo said:

I recommend against making your own texture map. Also, baked models I’ve always point into the block texture map, you would have to stitch your own texture map into the block texture map.

For clarity, my idea there was to have a single set of model jsons and do this, which would (from what I understand) ensure all variants are stitched onto the block texture map, even if they aren't directly referenced in the variant models. Since it does ruin the space efficiency of the generated texture atlas, I would probably instead look into the TextureStitchEvent to see if I can insert the textures there.

1 hour ago, Cadiboo said:

I think that the best thing to do is to make the json files.

As suggested, I tried making all of the json files. It gives me the desired effect, of course, but it also added a significant (i.e. noticeable/non-trivial) increase in loading time. It also turned my filesystem into spaghetti, forcing me to use subdirectories just store all of the variants for each json model to not clog things up. This is all for just one complex block, which means the problem could compound if I ever want to add similarly detailed multipart blocks.

 

This is really just an edge/corner-case issue, so using the normal route for this wouldn't be the end of the world, but I'd really prefer a less painful route. On the topic of baked models, something like this might be an option, especially if I use the TextureStitchEvent as I'd mentioned.

After a bit of digging and testing, I've determined a solution that is adequate, though not very clean. (Pinging @Okmeis so they can see if this works for them)

• Add all needed textures to the atlas using TextureStitchEvent.Pre.
• In ModelBakeEvent, grab all existing registered models relating to the block from the registry, then wrap each state's model in a custom baked model and replace the registry entry.
  • The custom baked model can then use the handy vanilla BakedQuadRetextured to "change" the texture of the wrapped model's quads.

This feels kind of hack-ish, but it does produce the desired results with a minimal impact on load times and no file-spaghetti. I'm sure a superior solution can be found, so I'm happy to try other ideas.