EminGT
commented
1 year ago Sorry for the late reply. To be honest the best advice I could give you would be to not bother making hundreds of blocks work, because it's impossible to make every single one of them look great without modifying the pack to add specific new sections for many of them. But anyways I will be adding a block ID to auto-detect modded ore pixels in the next update (r2.3)
Heya. First, just wanna say thanks. I'm really enjoying Complimentary Reimagined 2.22 in a 1.19.4 quilt modpack I'm building, and I love it's ability to be customized for slow computers, or be cranked up for those that can handle it. Currently I'm building the modpack to assume it will be present.
I'm struggling to get glowing ores from other mods to look correctly however. If I enable glowing ores in CR, even if I let a resource pack like Better Vanilla Building overwrite the vanilla textures, they look gorgeous. Presumably because of your emissive/RGB editing in terrainMaterials.glsl. However, if I use either of these resource packs to add emissive textures to other mods - https://legacy.curseforge.com/minecraft/texture-packs/modded-glowing-ores https://legacy.curseforge.com/minecraft/texture-packs/better-3d-ores
With shaders, iron and copper look fine-
With shaders, tin and silver look full on white, compared to what the texture of the block actually looks like at the top-
Without shaders but still emissive-
Now, comparing side by side, the difference isn't huge, I'll admit. The default textures are pretty bright. But it's enough that, when you come across an ore that's pure white, it just doesn't look great. So I've been looking for a solution, that will allow the ores to still be emissive, but look good with Complimentary Reimagined. I tried just darkening the texture.. but this was very difficult to balance, and usually ruined the look of the ore. Then I tried a mixture of lowering brightness while upping contrast (-50/50 in paint.net). This actually turns out fairly decent. But I'll have to do this with every single emissive texture that looks too bright, and then I'll run into distribution permission problems.
So I looked into what I could do on CR's end. I noticed playing with different tonemap settings helped.. but then everything else was changed globally as well. But then I read this - https://github.com/ComplementaryDevelopment/ComplementaryReimagined/issues/9 - and remembered looking at the block.properties and terrainMaterials.glsl, so I started experimenting with this. And.. this actually worked out for me!
I just have to match mod ores up to vanilla ores with similar color schemes. As an example
This allows the tin and silver to be emissive, without blasting them full white. So I'm thinking about attempting to do this with every single ore in my modpack - but obviously this will take a while and isn't entirely ideal; most people won't want to do this lol. I also risk the chance of finding a particular mod ore that won't fit any of the existing block schemes, requiring a new one to be added to terrainMaterials.glsl. Since this requires editing shader files, I'm not sure what the best/allowed option for distribution in a modpack would be though? Assuming this modpack ever gets released anyway. (Would a global datapack be able to override shaders\block.properties and shaders\lib\materials\materialHandling\terrainMaterials.glsl? 🤔)
Before I fully commit, what advice can you give me on the topic? And if I were to suggest adding mod compatibility for emissive ores, either in the way I'm going about it, or in a way that allows emissive resource packs to not turn into the surface of the sun, what would be the chance of that being added officially?
Edit: Immediately ran into some materials that didn't quite fit while testing a few. Like if you try to re-use copper ore for the andesite copper ore from universal ores, you end up with glowing specks all over. Which I fixed via 'color.g * 0.98'. But if I gotta modify terrainMaterials at all, I might as well just create separate IDs and not risk messing up the defaults. So until I hear back, I think I'll just play around with adding in all new IDs for extra mod blocks and their material handling, and leave all the default stuff alone.