Okay, some know that I am putting together model-to-render from few other models.

 

1. You craft 4 items which hold color in their NBT.

2. You use those 4 items to craft whole "thing".

3. The whole "thing" holds NBT of what from it was put together (obviously), so it also has colors.

4. The colorizing happens after returning model - so after my ISmartModel returns proper quads of those 4 parts.

 

That left me with 2 options: colorize inside ISmartModel - which would be dumb, too much to cache and too big headache.

So then I noticed that getColorFromItemStack has int renderPass.

 

Investigating lead me to belive that the "tintIndex" inside BakedQuad is the integer corresponding to renderPass.

 

Basically - would be my desing be "smart":

 

I assume that "layerX" (X = number) is the tintIndex of texture in item.json - is this true?

I would make each part have some tintIndex (part 1 has layer1, part 2 - layer2, etc).

And then apply colorizing on proper BakedQuads returned from part's model.

Is item allowed to have e.g layer55 but not have any layer before (0-54 in this case)?

Will those indexes be used somewhere in future?

Hmm, thread might have been prematurely created.

 

Anyway, for those interested:

.json allows your item to have maximum 5 layers, from 0 to 4.

Layer 'n' can't exist without layer 'n-1' - so you cant have layer1 without 0. Doing so will break all layers. (no texture).

TintIndex in BakedQuad is the renderPass corresponding to layerX used in .json to generate quad of model.

 

There is no easy way of altering colorizing process aside from coloring quads on your own in ISmartModel.

 

As to overkill ways - I extended BakedQuad with LayerBakedQuad and added setTintIndex() to set renderPass to whatever I want, without having the layer in .json.

The LayerBakedQuad are being created the moment of model creation and replaces all normal BakedQuads, tintIndexes are now not from 0-4 but in 0, 100, 200, 300, 400, which allows me to put any other values between them to add special coloring phase in final model put together from those parts.

 

Total overkill but works and is "smart".

 

Oh, and results:

I know this post Is like a year old, but thanks, this was actually very useful

I'd just like to add:

1.8 was time when all sorts of hooks were being added to rendering systems (they still are).

The "trick" I did there was of "times require it" sort, but "times change" and that may no longer be good now.

Thing that I'm saying - if you are planning on updating to 1.9 anytime soon (where rendering changed again a bit), you might look into other solutions - I can't say this approach still works now (1.9), but it might.

This time i will reply 6 months later, improvement 

 

Can confirm that this does still work in 1.10.2 with a slight change, you are now required to implement IItemColor and then register it in the the post init on the client side only with:

 

Minecraft.getMinecraft().getItemColors().registerItemColorHandler(IItemColor , Item);

 

Im guessing some variation of this system will always remain in due to mob eggs using it, but again just a guess

 

if anyone ever actually reads this post and wants an example check out TheGreyGhost's example:

https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe11_item_variants