Blocks like Draconium Ore from Draconic Evolution do not properly create an overlay or resource. Sometime this week I will try to modify the overlay extraction to support animated textures and submit a pull request. This will not support animated backgrounds but instead of will iterate at specific intervals to create the merged texture from the texture list. https://github.com/brandon3055/Draconic-Evolution/blob/master/src/main/resources/assets/draconicevolution/textures/blocks/animated/draconium_ore.png Example image of what an animated texture looks like (it is just each frame under the previous frame and it loops. I think Minecraft does this automatically if you load the texture as it). I also will need to test how the animated dense ores look and potentially modify it slightly.

I may end up needing help having it create animated variants once I have the overlay.

Edit: I also am going to need to make it so that it can support different scaling backgrounds. For example some ores from NuclearCraft are 32by32 textures but minecraft stone is 16 by 16 so it crashes from failing to create a resource.

I did notice that. That sounds pretty sick and much appreciated. Thank you!

Update on progress: So far I have rewritten my getDifference algorithm to try and improve its accuracy, and at least for stone background blocks it is working well now. The only error it has (which for auto generated things is fine) is that amber ore has a hard dark pixel that is supposed to be part of the background. https://gyazo.com/b115d6eddb56578c6c85f4fc852f8b3e

I will test its extraction on ores from other dimensions a bit later and then start work on allowing it to handle animated textures. (Should be relatively easy to do for overlays though the texture stitcher may need to be modified to ensure that it has the background behind all frames of the texture.

Edit: I am looking into Nether ores some more as at least Quartz ore has issues being extracted. End ores from what I can tell mostly work (Amethyst ore from BOP works properly) Ender Biotite Ore from Quark has a couple minor issues but for an auto generated image I believe that the end ores are also now in an acceptable state: https://gyazo.com/426e52b63552234ae7b85ab6b3379634

Not bad. Nice job.

Ok, then later today I will spend a little and make the shiftImage method not have the animated textures blend across frames if they reach to the edge of each frame. After that I will create a pull request and we can figure out what is required to have it render the overlay.

I have a new version of getOverlay that I can submit if you wish; HOWEVER, there are a few things to note with it.

1. I have not changed the shiftImage method. If you want I can have it do it based on the width of the image, though this will make it so it requires the image to be square (or w*h by w). The reason I did not do this yet is that from the one animated ore I know of (draconium ore from Draconic Evolution) the extracted overlay does not have "border" pixels so it does not end up generating interference.

2. I have not yet looked into how you bake the overlays onto the blocks. If you I can try to look at it when I get a chance or I can just submit the pull request and then you can work on stitching the overlay and background together. (I believe the way that it will need to be done is to stitch them multiple times with the background being shifted.)

3. I have not yet done any work on if the background and given ore are different texture sizes (32x32 and 16x16), and I may save this for a different pull request.

1. There are also some animated ores from Thermal Foundation, but I never added support for them. I kind of rushed getting that update out, because playing with that mod and testing things in-game are at least as complicated as writing this one. Do images need to be square, though? It should be possible to get the number of times to shift an image using num = width / height, where height is always a whole number multiple of width (because all frames are square). Then you can just write a loop, where for each iteration, the input/output y coordinate = itself - (currentShiftNum * width), each time calling shiftImage for those coordinates. Sorry if that comes off as condescending; it is supposed to be an actual question.

2. I don't actually stitch any images together. Minecraft handles all of that for me. I'm just lazily rendering multiple images at once using its built-in block model system. So in other words, in order to get this to work, I actually would need to create a new background image for each block, which could prove to be very difficult; all images need to be registered sometime before the models are baked, but I also don't know anything about a block's textures until ModelBakeEvent. I may be able to solve this by using BlockRenderDispatcher, which is available before ModelBakeEvent, but I also need for everything I do to happen as late as possible because the time frame during which other mods register their blocks / models can be fairly inconsistent (especially with Quark, which is already a dependency).

3. What's the issue with this, again? I may need to go back and read over what you've written, but I was under the impression that everything should be fine so long as both input textures have the same dimensions. Is there ever a time when one mod adds 32x ore textures, but not 32x stone textures?

Edit: a quick update for number 2: that isn't actually true. Because the images don't have to be stitched together, and especially because we're using resources.zip / a resource pack, there's no issue here.

1. I am aware of HOW I would do it, I was just unsure if we care about assuming it is an animated texture if it is not square/assuming that the animated is for square textures (which I believe should always be the case for ores so maybe we can assume this)

2. Ok

3. NuclearCraft Lithium, and Boron are 32x32 textures, I do not believe they pack a 32by32 stone texture in. The other ores from this mod for example magnesium are 16x16 textures.

Okay, then.

Also, I forgot this before: if you're worried about assuming that a texture is animated, there always has to be an imageFileName.mcmeta associated with every animated texture. We could always just test for that, but it probably isn't necessary because all cuboid block models require square textures, unless they are animated. I'm assuming there are no ores without cuboid models, though.

About number 3, I should be able to write a small function to scale images. We have access to Graphics2D, which I believe lets you rewrite a BufferedImage with new dimensions. That should be good enough.

Okay, sure. Thanks!

Okay. Here's where we are on this issue. Let me just upload the changes here, try to fix a bug really quick, and then I should be able to get a release out by the end of the day.

And a final update from me: Here's the status on using scaled backgrounds. You can see, there's one extra pixel (scaled) that got left behind. On the other hand, at least one texture (iron ore) is missing a single pixel, and will instead need to be included in the next release.

That's pretty damn good overall, though.

Edit: And of course, overlays which were previously more than 70% empty will now continue regenerating, where on each iteration, the alphaPercent is reduced in half until the that threshold is met.