Depending on if my model is in the overworld or the end it looks different.  In the overworld, the endstone texture is completely blacked out, and if the end it works just fine.

Model file:

{
    "parent": "block/block",
    "textures": {
        "particle": "blocks/end_stone",
        "endstone": "blocks/end_stone",
        "ore_overlay": "selimrandomstuff:blocks/onyxore"
    },
    "elements": [
        {   "from": [ 0, 0, 0 ],
            "to": [ 16, 16, 16 ],
            "faces": {
                "up":    { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "up" },
                "down":  { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "down" },
                "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "north" },
                "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "south" },
                "west":  { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "west" },
                "east":  { "uv": [ 0, 0, 16, 16 ], "texture": "#endstone", "cullface": "east" }
            }
        },
    {
    	"from": [ 0, 0, 0 ],
            "to": [ 16, 16, 16 ],
            "faces": {
                "up": { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "up" },
                "down": { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "down" },
                "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "north" },
                "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "south" },
                "west":  { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "west" },
                "east":  { "uv": [ 0, 0, 16, 16 ], "texture": "#ore_overlay", "cullface": "east" }
            }
        }
]
}

I assume the problem isn't here, but here is the block class:

package selim.randomstuff.blocks;

import net.minecraft.block.Block;
import net.minecraft.block.material.Material;
import selim.randomstuff.ModInfo;
import selim.randomstuff.SelimRandomStuff;

public class BlockOnyxOre extends Block {

public BlockOnyxOre() {
	super(Material.ROCK);
	this.setRegistryName("onyxore");
	this.setUnlocalizedName(ModInfo.ID + ":" + "onyxOre");
	this.setCreativeTab(SelimRandomStuff.randomThingsTab);
}

}

 

I have a feeling it is a dumb little thing I am forgetting as I have done similar things before and fixed it, just can't see where when I look back.

Anyone?

I'm thinking it might have something to do with block lighting, but I don't know how to fix it.

Why not just use a new texture for the block, instead of having to use endstone with an ore overlay?

 

Unless there is something I do not know, and 1.10.2 forces you to do this... (I have a 1.10.2 mod with ores so you do not need to do this...?)

Why not just use a new texture for the block, instead of having to use endstone with an ore overlay?

 

Option A:

- 192 textures for [material] + [ore]

Option B:

- 12 material textures + 16 ore overlays

 

Hmm...

Well I must be stupid, or missing something. I do not understand

Why not just use a new texture for the block, instead of having to use endstone with an ore overlay?

 

Option A:

- 192 textures for [material] + [ore]

Option B:

- 12 material textures + 16 ore overlays

 

Hmm...

What-so-ever, so I must be an idiot

Compare:

To:

https://github.com/Draco18s/ReasonableRealism/tree/master/src/main/resources/assets/harderores/textures/blocks/ore

 

And that's just 10 ores in that image.

Wait, so why do you need 16 images per ore/block?

 

Am I totally out of the loop???

Wait, so why do you need 16 images per ore/block?

 

My usage is different from Selim's.  But if you're making ores that you want to be made of any material (gravel ores, sand ores, sandstone ores, granite, diorite...) then you need to have a base+overlay if you want to match altered textures in the case of resource packs.  You always want your overlay to paste on top of whatever the "stone" block is.

I got excited because there was actual discussion on the issue, then it stopped again.

I am not understanding how that's even working in the first place.

 

When you got 2 overlaping texture faces it should cause Z fighting.  Might be that your graphic card picks one tex over the other depending on some random thing.

 

You should always see both textures going in and out between each other.

 

My guess is your problem is at different heights/positions one texture takes precendece over the other.

 

 

 

 

Since both occupy same space you should get glitches.

 

I mean to make sense of what you're trying to do  I'd make the overlay cube a tiny bit bigger like 0.01 bigger but keep uv mapping same so stretch the tex by 0.01 i think you uv lock all faces. This will prevent the overlay cube to be in the same space as the block cube.

 

Then you'd need to enable cutout rendering for the block like leaves does. Then all transparency will be cut out. Like leaves does.

 

Is it always blacked out in the overworld? Is it always perfect in the end? What about the nether?

Wait, so why do you need 16 images per ore/block?

 

Am I totally out of the loop???

 

the main reason you don't wanna use 16 images or pre-set variations textures is tex packs!

 

If you install a modpack all your custom textures will not be compatible and your ore will look vanilla. Re-using in game textures is way  smarter and your mod becomes insta compatible with any texture pack.

It is black in the nether as well.  I have other blocks that work the same way with overlayed textures that work just fine, but they emit light.  That could be the reason they aren't doing this if it is actually because of issues with block light.

It is black in the nether as well.  I have other blocks that work the same way with overlayed textures that work just fine, but they emit light.  That could be the reason they aren't doing this if it is actually because of issues with block light.

 

What I'd recommend doing then, is looking at the WorldProviders for the dimensions. Look for things that are in both the Nether & End providers , but aren't in the Overworld provider. It may help narrow down the cause.

 

try this in your constructor

this.useNeighborBrightness = true;

What I'd recommend doing then, is looking at the WorldProviders for the dimensions. Look for things that are in both the Nether & End providers , but aren't in the Overworld provider. It may help narrow down the cause.

I assume you meant Overworld and Nether, those are the ones that are the same, End is different.

 

 

try this in your constructor

this.useNeighborBrightness = true;

Nope

Nevermind, got it.  I don't know why this changes things depending on dimension, but I changed the block render type to mipped cutout.

Pretty sure your issue  is what I said above. Putting 2 blocks one inside the other with overlapping faces should cause tex flickering. Maybe your card makes the decision to put both in order in lighter environments and to blend the two textures in darker environments. On my system the texture flickers between the two whenever i have overlapping faces.

 

Rule of thumb is you cannot have 2 textures occupying the same space. Which you still do even after it works now. . You may still get reports from people that your ore tex is flickering when you release it. Hopefully not. 

 

tex is flickering

 

That's called z-fighting and that is not what is happening here.

Pretty sure your issue  is what I said above. Putting 2 blocks one inside the other with overlapping faces should cause tex flickering. Maybe your card makes the decision to put both in order in lighter environments and to blend the two textures in darker environments. On my system the texture flickers between the two whenever i have overlapping faces.

 

Rule of thumb is you cannot have 2 textures occupying the same space. Which you still do even after it works now. . You may still get reports from people that your ore tex is flickering when you release it. Hopefully not.

You do realize that vanilla grass blocks do the same thing right?