[1.8] [SOLVED] TintIndex: Anyone gotten it to do anything useful?

[Zaerudath]

I would like to use it to shade some textures instead of creating 16 textures per block that are subtly different shades of the same texture. 

 

This, for example, seems to do nothing:

{
    "textures": {
        "face": "oddities:blocks/unob_block_a",
        "particle": "blocks/stone"   
    }, "elements": [
        {   "from": [ 0, 0, 0 ],
            "to": [ 16, 16, 16 ],
            "faces": {
                "down":  { "texture": "#face", "cullface": "down", "tintindex": 255 },
                "up":    { "texture": "#face", "cullface": "up", "tintindex": 255 },
                "north": { "texture": "#face", "cullface": "north", "tintindex": 255 },
                "south": { "texture": "#face", "cullface": "south", "tintindex": 255 },
                "west":  { "texture": "#face", "cullface": "west", "tintindex": 255 },
                "east":  { "texture": "#face", "cullface": "east", "tintindex": 255 }
            }
        }
    ]
}

 

 

I've looked at the vanilla JSON files (they all have tintindex 0). Not much on the web.  I've tried to trace it down in the vanilla code but it doesn't seem to be referenced directly.  I started tracing through the various render-related classes and then thought to come here and ask.

 

I know there are other ways to do it, but has anyone gotten tintindex to do their bidding?

 

edit: added 1.8 tag

 

[jabelar]

The description here: http://minecraft.gamepedia.com/Block_models says the following about tint index:

 

"Determines whether to tint the texture using a hardcoded tint index. The default is not using the tint, and any number causes it to use tint. Note that only certain blocks have a tint index, all others will be unaffected."

 

So basically they seem to be saying that it is pretty much a boolean (0 is false, all other numbers are true) and it only works for those blocks that already have a tint index "hardcoded".

 

A search for any field with tint in the name only gives useInventoryTint in the RendererBlocks class.

 

Overall I'm not sure what you can really do. The BlockLeaves and BlockGrass have a getRenderColor() method but they return hardcoded stuff so you can't really directly change them.

 

 

[Tschallacka]

I believe its for biome colouring. Like leaves and grass changing colour in different biomes.

 

So you would set tint index to true and and implement the change color upon biome thing.

 

If 1.8 still supports custom block renderers you could patch in a shader there that shades the vertexes to the color you want.

 

 

[TheGreyGhost]

Hi

 

A bit of background info here

http://greyminecraftcoder.blogspot.com.au/2014/12/block-models-18.html

 

The “tintindex” flag is used for faces which get a colour from Block.colorMultiplier() to modify the rendering colour – for example used by grass to change to a brownish colour in drier biomes, or by redstone wire to change the wire brightness according to the power level.

 

eg in BlockModelRenderer::

            if (bakedquad.hasTintIndex())
            {
                int i1 = blockIn.colorMultiplier(blockAccessIn, blockPosIn, bakedquad.getTintIndex());

                if (EntityRenderer.anaglyphEnable)
                {
                    i1 = TextureUtil.anaglyphColor(i1);
                }

                float f = (float)(i1 >> 16 & 255) / 255.0F;
                float f1 = (float)(i1 >> 8 & 255) / 255.0F;
                float f2 = (float)(i1 & 255) / 255.0F;
                worldRendererIn.putColorMultiplier(f, f1, f2, 4);
                worldRendererIn.putColorMultiplier(f, f1, f2, 3);
                worldRendererIn.putColorMultiplier(f, f1, f2, 2);
                worldRendererIn.putColorMultiplier(f, f1, f2, 1);
            }

 

-TGG

[Zaerudath]

Aha!  Found it. The tintindex in the block model file is indeed a boolean as jabelar suggested.  Any value other than -1 will be interpreted as true. 

 

For it to do anything, you also have to override Block.colorMultiplier.  It initially seemed to do what I wanted.  I had hoped to use it to shade the block based on blockstate while using the same block model for each block state.

 

Sadly, looking at BlockModelRenderer, it appears this won't actually work reliably because colorMultiplier is only applied if ambient occlusion is enabled.  It also won't work if the block is a light source, though that doesn't apply in my situation.

 

TheGreyGhost:.  I had read that before but didn't make the connection. I read it again and it clicked this time.  The material you have online is supremely useful, and much appreciated.

[TheGreyGhost]

TheGreyGhost:.  I had read that before but didn't make the connection. I read it again and it clicked this time.  The material you have online is supremely useful, and much appreciated.

Thanks

 

Are you sure that Block.colorMultiplier only works with Ambient Occlusion enabled?  I see this in renderModelStandardQuads(), which is used when AO is off:

            if (bakedquad.hasTintIndex())

            {

                int i1 = blockIn.colorMultiplier(blockAccessIn, blockPosIn, bakedquad.getTintIndex());

 

-TGG

[Zaerudath]

TheGreyGhost:.  I had read that before but didn't make the connection. I read it again and it clicked this time.  The material you have online is supremely useful, and much appreciated.

Thanks

 

Are you sure that Block.colorMultiplier only works with Ambient Occlusion enabled?  I see this in renderModelStandardQuads(), which is used when AO is off:

            if (bakedquad.hasTintIndex())

            {

                int i1 = blockIn.colorMultiplier(blockAccessIn, blockPosIn, bakedquad.getTintIndex());

 

-TGG

 

I'm only sure of death and taxes.  That does look promising.  Will do some testing later this evening.  Would be great if it works in the general case.

 

You might know: I tried to track down how vanilla handles  blocks like colored wool.  I got as far as BlockColored last night before I ran out of time. That class doesn't override colorMultiplier, and the base class implementation returns a hard-coded 0xFFFFFF.  Will keep looking if you don't know.

[TheGreyGhost]

Wool uses different coloured textures, eg wool_colored_black.png, wool_colored_red.png, etc

 

-TGG

[Zaerudath]

Wool uses different coloured textures, eg wool_colored_black.png, wool_colored_red.png, etc

 

-TGG

 

Yes, not just different textures but it appears Mojang created distinct blocks for each color. Was just browsing the vanilla blockstate folder and each color has its own blockstate file.  It seems Mojang stopped using metadata for most or all colored blocks. 

 

I  imagine they didn't use tint index to allow for more interesting and varied textures on colored blocks than could be had just by tinting a single base texture.  But I do wonder why they stopped using metadata (now block states) altogether unless they just don't care about conserving block IDs any more.

 

Also, I tested tint index to confirm that it does work irrespective of the lighting model.  That is going to save me a lot of tedium in creating textures. I want some blocks to get progressively darker as they absorb damage from explosions, and I can just override colorMultiplier to be based on blockstate and let all the blockstate variants point to the same model.

 

Thanks again.