Header

This is a mod that allows resource packs to add biome tint colors/indexes, basically biome coloring for grass, leaves and water, and give transparent biome-overlay textures to pretty much any* block. *(see notes for 1.18.2 and below)
This mod also includes a few resource packs for vanilla that are extracted to the resource pack folder & enabled at startup.

For other resource packs that I didn't include by default I should have a page up in some time.

Requirements / Compatibility

See table below.
Compatability

1.12.2 & 1.16.5 - Suffers in vanilla from visual layering glitches with translucent textures
1.18.2 and above - These versions implement the tripwire shader properly so one can have translucent textures for things like flowers that are not 6-sided blocks.

If you want/have to use a shader pack that fix the translucency issue, I tested a few and these work on 1.16.5:

AstraLex v90.0
BSL v8.2.02
Complementary Shaders v4.7.1
Complementary Reimagined r2.03
For 1.12.2 & Optifine you can also just use the included "(internal)" shaderpack, as this looks exactly like normal MC, but also fixes translucent textures with a small performance hit.

Notes - What does "pretty much any* block" mean?

1.19.2 and above
Should actually be all blocks.

1.18.2
It means all blocks that are allowed to use Forge's ItemBlockRenderTypes.setRenderLayer() method.

1.16.5
It means all blocks that are allowed to use Forge's RenderTypeLookup.setRenderType() method.

1.12.2
It means all blocks from vanilla and all modded blocks that don't override the getRenderLayer() method.

How do I make a resource pack that uses this?

I won't get into how to generally make a resource pack, please go somewhere else for that and then come back.

Please also read the first point in the short term to do list.

In general there are two ways to add tint colors (and in 1.18.2 and below RenderTypes/BlockRenderTypes) to blocks.
editing *.json model files
This method just uses the already existing foundation of the .json model files. I extended the functionality of these to include being able to add color tints (and in 1.18.2 and below specify the render type).
bcfp.ini file in the root of the resource pack
This should only be used as a backup method, if the model really doesn't want to accept being edited by the .json method. Usually should only be applicable to older versions of MC.
You can create a file called bcfp.ini in the root of the resource pack and define what tint colors (or render type for 1.18.2 and below) a block is supposed to have.
These are only applied at startup and are not reloaded dynamically.

What you have to do with both methods

In both cases we do have to edit the .json model file.

"Parent" tag

We have to actually point towards an existing parent model file with the "parent" tag or make our own model.
I included a bunch of altered parents model files for the already existing model files in minecraft. The easiest way to edit your .json file is to take what is in the "Original parent" column and replace it with the "Parent w/ overlay" column. The "block/" or "minecraft:block/" part should be kept.
parent tag

Example:

"parent": "block/crop_with_biome_overlay_modern"

In the case of 1.12.2 there is also "crop_with_biome_overlay_modern". This just ports back a fix from newer version where the texture of the opposing sides of a texture are actually mirrored, so that it looks like that pixels are physically in the same place for the opposing sides. The included vanilla resource packs use this.

For all the above you also have to specify a new overlay texture. Usually the overlay texture name is just "overlay".
In the case that a model may have multiple overlay textures, e.g. "cube_with_biome_overlay", there is a copy of every texture name with "-overlay" appended.
In exception to that is the flower pot model, since we only care about the plant in the pot anyway.

There is also a version for every one of these altered model files with a second overlay that is just the same name with a "2" appended at the end and another overlay texture with also "2" appended. I admittedly did not test these as I didn't find a use for them.

If you make your own .json file - "tintindex" tag

When making your own model instead of relying on the "parent" tag you also have to specify the tint indexes that are used for the faces that have them.
I would just look at sunflower_top.json in the default flowers+plants resource pack to get a feel for them, but basically every block tint color that is applied gets a tint index starting with Nr. 0 (-1 is internally when no tint index is to be used) and counting up.

You can also extract the .jar file of this mod with 7zip and look into "assets\minecraft\models\block\" as there are the altered parent model files provided by this mod, to get a better understanding how to write your own model. Please however do not redistribute these with your resource pack.

Block/Tint colors

*.json method

To add a tint color you have to use the "tintcolor" tag at the root of your .json (so where the "parent" tag usually is).
The following are valid tint colors:

grass
leaves
water
startup - This is the block color that is there after the startup, useful if a block already has a block color initially and we want to add another.

Example:
"tintcolor" : "leaves"
Example of multiple tint colors:
"tintcolor" : ["startup", "grass"]

In the above case the startup tint color will have the tint index 0 and the grass tint color will have the tint index 1.
There may be cases when the startup tint color actually already uses multiple tint index, in this case you should be able to specify the "startup" tint color multiple times.

Do note that if you use any of the altered parent model files that this mod provides, that these all already have the tint color of grass applied to them, so if you want a grass tint color you don't have to specify it.

An exception to this are the altered model files starting with "stem" as these in vanilla already have a block color, so they have the tint colors "startup" & "grass".

The version with 2 overlays additionally have a leaves tint color.

bcfp.ini method

In general we first have to add a block to our newly created bcfp.ini file. These use the usual <namespace>:<location> format. For example stone in MC has the namespace "minecraft" and the location "stone" as such our initial string would be "minecraft:stone".
After that we can specify one of the following:

!grass
!leaves
!water
Example:
minecraft:cobble_stone!leaves
Example with multiple tint colors:
minecraft:cobble_stone!leaves!grass

Lines in the bcfp.ini file that are empty or start with # are ignored.
If you have trouble knowing what the <namespace>:<location> of a block is you can usually in-game hold F3 and then press H to enable showing it on hovering over a block in your iventory.
If no tint color is specified if defaults to using the !grass one.

Render type

We also have to specify how the game renders our block.

*.json method

If you know modern resource packs you should probably already know this, but I also implemented this for 1.18.2 and older.
The tag for this "render_type" and is also at the root of our .json file.
Valid values:

minecraft:tripwire - Fixes the layering glitch with minecraft:translucent, should be used if you want none 6-sided block with transparency. Not available for 1.12.2.
minecraft:translucent - Useful if you want to add an overlay to a 6-sided block with a solid texture. Has an ugly layering glitch when used with none 6-sided block models like plants.
minecraft:cutout_mipped - Mip-mapped version of cutout, usually used for leaves. See below.
minecraft:cutout - Most flowers in vanilla. Has pixels with either complete transparency or no transparency. The cut-off point of being transparent for a pixel is 30 % or 76/256.
minecraft:solid - Normal blocks without transparency. Pretty much completly useless for us.

Example:
"render_type" : "minecraft:tripwire"

In general for us the most useful one is tripwire (or translucent in 1.12.2).
For older version it is to be said that multiple blockstates (basically one blockstate = one *.json file) have to share a rendertype, as the rendertype is bound to a block. Because of this the mod looks through all possible blockstates of a block and uses the one highest in the list above.

bcfp.ini method

This method is only valid for 1.18.2 and below.
Valid values:

!tripwire
!translucent
!cutout_mipped
!cutout
!solid

Example:
minecraft:stone!grass!translucent

For information of the values see the *.json method.
If there is no value specified it defaults to using the !tripwire one.

To-do List

Short term / a few weeks

Sometimes with a sodium derivative the rendertype is only changed at startup. Mostly important for resource pack makers, as they do have to restart the game if they want to change the render type.
~~Port to fabric starting with version 1.18.~~ See FAQ.
Look into determing if a shader is being used as the tripwire shader is often ignored when it comes to shadows and set the render type to translucent if needed.
Long term
Maybe look into fixing the graphical bugs in older version so that no other mods are needed.
Mayyyybbeee look into porting to 1.7.10 again.

FAQ

Q: Is there any performance penalty?
Yes. Since the GPU has to draw additional triangles for every overlay, there is a slight performance penalty. In a flower forest I get around 1-2 % less FPS with Rubidium.

I did once make a giant diagonal wall of about +270.000 flowers. Looking at it all directly caused me to drop like 18 % of my FPS with the mod, but I don't think that is very realistic.

Q: Fabric port when?
~~In a few weeks probably.~~ Will look into porting the resource packs to the custom color Optifine format, since there are a few mods that port the functionality like Vanadium Colors & Colormatic.

Q: Source code release when?
At some point. Probably after the port to fabric. I want to clean up a bit before, as I have never released source code on the Internet before.

Q: Will you generally update the mod for older Minecraft version that already had a release of this mod?
Yes, as long as the updated functionality makes sense for this MC version.

Q: Will you update the mod for a minor version that isn't the newest of a major version?
No.

Q: A new MC version is out and Forge has a beta release, will you update the mod now?
I won't update as long as Forge doesn't have a stable release. You can however try to use a version for the last minor MC version, as I don't disallow the mod to run on newer minor version of MC.

JohnBaccarat