Closed Xuerian closed 7 years ago
FoamFix 0.3.2a?
foamfix-0.3.2a-law.jar, yes
I have reasons to suspect why this happens. I'll look into it tomorrow.
For the time being, please try disabling options in foamfix.cfg one by one until you find the culprit, if any.
If it's BF that is throwing a wrench in your gears, drop me a line and we'll work it out. I try to be accomodating.
@asiekierka Will do if I get the chance tonight.
@octarine-noise No need to - as an optimization mod, it's my responsibility to do my best to accomodate mods, not yours. I'm the one breaking expectations.
If you want to help, it'd be nice if you could outline how you grab the textures (during what phases of loading, using what data, etc.) - it would be very helpful for trying to figure out what part of what optimization breaks said expectations. I'm not the most familiar with Kotlin, sorry.
Sure thing. I'll give a high level overview, and you can query me on the specifics if something is unclear. Wall of text incoming.
I have an ASM tranformer and call hook in place that fires an event during resource loading - right after model definitions are loaded but before model baking takes place. This allows me to inspect the models with all information still present (like model inheritance, texture names, texture locations) and establish a link between models - more specifically, the interesting information I extract from the models, like the ResourceLocation for the "heart" and "bark" textures of a log block, that kind of thing - and IBlockStates, and later (during TextureStitchEvent.Pre) the actual IIcon instances in the atlas.
All this so far is just read operations, no manipulation. The only monkey business here I can think of is that I manually inspect some textures during pre-stitch (as in, get stream from resource manager, load into BufferedImage, check for overall tint).
Synthetic textures (in case of leaves, and some other minor stuff) are also registered in the atlas during pre-stitch, using good old TextureMap.registerSprite(). These textures are organized by type under specific resource domains, each backed by a generator object, which together form a pack implementing IResourcePack. This pack is added during startup to FMLClientHandler.instance().resourcePackList, so they are always present and invisible in the resource pack GUI. The textures have names which contain special (pipe and equals) characters, as they encode parameters for the generator - like type, or the ResourceLocation of the real texture they are based on, etc.
AFAIK I do nothing that should affect regular (non-generated) texture loading. The relevant code is a bit smeared across the codebase, in several event handlers, each doing a small fragment of the whole song and dance, so it's not possible to give good, understandable end-to-end examples. I hope this was still useful.
@octarine-noise Thank you very much!
@Xuerian Disable the "clearDuplicateModelRegistry" optimization and let me know if it helps. (What that optimization does is essentially wipe the model registry caches before TextureStitchEvent.Pre, as they should no longer be necessary - i can move it to .Post)
@asiekierka Will do when I get back from out of town. Thanks for looking into it. FoamFix has already helped my friends and I quite a lot.
@octarine-noise Nice. Thanks for showing up and helping out. Can't play without BetterFoliage.
@asiekierka Back. clearDuplicateModelRegistry doesn't help.
I got curious and tried to check this out. I used the following mod versions:
in numerous combinations, and I got nothing. No texture errors or rendering glitches of any kind. I didn't touch any configs, just running on defaults.
The issue might be hardware-related, or caused by interaction with a third mod.
@octarine-noise Well. I should've done minimal test setups myself.
Use this:
Compare to: BetterFoliage (2.1.1)
You should see pink grass in 2.1.2 and not in 2.1.1. Doesn't seem to be related to FoamFix at all. No idea what is at fault, though.
@asiekierka OptiFine's Fast Renderer option by itself causes black leaves on the minimap, and FoamFix doesn't seem to have any impact on that. I can't reliably get them to interact in any weird way in the clean setup, but there's a lot of options to fiddle with. I managed to get a rainbow colored minimap at some point while writing this post, but I can't reproduce it. Safe to assume FoamFix isn't at fault and I mis-reported, I think. Sorry!
No problem. I learned something new, anyway :)
https://minecraft.curseforge.com/projects/better-foliage https://github.com/octarine-noise/BetterFoliage
Many textures shown by BetterFoliage are purple when using FoamFix. Made for an interesting minimap view with mapwriter, and the latest BetterFoliage update spread the issue from just mapwriter to the gameworld itself.