Resource Pack Extraction Support
pupnewfster opened this issue · 11 comments
It would be interesting at some point to see the texture extraction algorithm work with resource packs. As of the moment how it works is it extracts the image from the base ore texture from the base stone texture. It overlays the texture properly onto the resource packs stone (as expected).
I imagine this may be rather difficult given
- The resource pack may load too late to be able to extract the textures from it
- If some mods are not supported by the resource pack, weird things may happen trying to extract from a vanilla stone ore texture when assuming the background is the resource pack ore.
One potential workaround would be if there was some way to make a config file that a user could specify a resource pack and which ores it supports and extract it from the resourcepacks zip file.
Good idea. The first part shouldn't be an issue, because it seems that Minecraft loads external resources pretty early on. At least, definitely before TextureStitchEvent, which itself comes before ModelBakeEvent, which gives me plenty of time. Actually, this might be pretty easy overall. I could probably use the resource pack list from Minecraft.getMinecraft().getResourcePackRepository().getRepositoryEntries() to test each resourcepack in order for the textures. I assume the worst thing that would happen is the textures just wouldn't generate very well.
Which resource pack are you using? I might try this out.
I was curious what it would look like with the pack I used to use so the pack I tested it with was https://www.johnsmithlegacy.co.uk/index.php Overall the ores looked pretty nice, but I am curious to see what they would look like with the built in textures. Especially given the diamond texture is animated in the resource pack and I know at some point we added support for extracting animated textures.
Believe it or not, I actually tried to create some overlays manually from these textures when I was working on Conquest support and couldn't get them to extract nicely. I have a fourth algorithm that works a lot better for these textures that are blended into the stone instead of just contrasting it sharply, like vanilla style does. Basically, it uses a filter to remove colors, instead of completely cleaning unwanted pixels out. So if the background is gray and the ore is green, but there are some greenish-gray pixels in between, those green-gray pixels will be converted to green pixels at lower opacity. Extremely WIP, though. Not great for a lot of textures. I wish there was an easier solution to getting these 32x textures to look nice, but not a chance.
Anyway, there's no harm in doing this. I should be able to write this in just a minute or two. Just need a little while to test it.
It must have been the height. That's odd. Sorry, I guess I just didn't have the newest version of the pack or something. I just made some changes to where the mask gets scaled the same way as every other image, which I assume was causing the problem. This definitely works for me, using JSL 1.12.2 v5.
Edit: This may look a little better if it would know to switch to all blended textures, but oh well. I'm still seeing a lot of missing pixels in some places and too many pixels in others. :/
It loads up without crashing now, and I do agree it looks a little weird with some of the pixels.
The main reason I made this issue is as something that probably should be done at some point, there is no rush to get it done.
On a slightly different note, as of version 3.0 it seems that some of my custom ores are not being registered to the correct oredictionary entry anymore. Given I wanted to change a decent number of the properties and not include all of the other ore types I added my own thermal expansion versions of ores.
thermalfoundation_aluminum_ore is the folder and I have it assigned to minecraft so that it does not get disabled by me having thermalfoundation integration disabled. However, as of version 3.0 it has started changing the ore dict name to oreThermalfoundation_aluminum
That makes sense. The mod name is stored as a variable now. It's no longer based on the beginning part of the string to potentially improve compatibility with some mod names. It's property group based now (unless the group is custom). Changing that meant it couldn't replace what it tried to replace. I could just change it back, but what that would do is just use the word that comes before "ore." That doesn't give me what I'm looking for when the name of the ore contains additional underscores. The easiest solution is to provide an optional field within OreProperties.json for the name of the ore, but I'm really trying to keep these things easy to use and, also, realizing that including the name could fix the issue would not be obvious to most users. Let me think about how I want to approach this first before fixing it.
This does work. Still working on the extraction algorithm itself, of course.
Haha I figured it wasn't ready for release. Let me see if I can figure out why the image isn't scaling correctly. Are you using 512x textures?
I don't believe so, though maybe some of the modded ore textures are? Though I doubt it given it is supposed to be a 32x resource pack.