[SOLVED][1.8] Light bugs with models (face-dependent brightness and black faces)

[Zyfarok]

Hello there !

 

I'm trying to create some "slope" block (45° slope) which work exactly like stairs... I'm a beginner so it was hard but I arrived to this result (using BakedQuads in a ISmartBlockModel) :

(Do not look at the bedrock texture, it's temporary)

 

 

 

 

In first view, it looks good, But in fact it's not really good :

- [solved] The first point/bug is that the brightness of the faces is always 100% (it should be 80% on north/south faces, 60% on east/west faces and 50% on the bottom) :

 

https://raw.githubusercontent.com/Zyfarok/Stairs-Test/master/not_shaded_by_direction.png[/img]

 

 

- [Not Solved] The second point/bug is that there is false lighting on itself and also on other blocks :

 

https://raw.githubusercontent.com/Zyfarok/Stairs-Test/master/bad_lightning_on_itself.png[/img]

https://raw.githubusercontent.com/Zyfarok/Stairs-Test/master/bad_lightning_on_others.png[/img]

 

 

 

I don't understand because my block is extending "BlockStairs" so it has the exact same properties, and I also tryed to change every possible parameters in the model.

 

A "solution" to the second point is to set the "lightOpacity" to 0, but it's not really what I want and the vanilla stairs doesn't need it !

 

To go further I tryed to create an exact copy of the vanilla stairs using the same model json file here : https://github.com/Zyfarok/Stairs-Test

and I don't understand why but the result is different than the vanilla stairs (the second point/bug isn't fixed, but the first seems to be gone) :

 

https://raw.githubusercontent.com/Zyfarok/Stairs-Test/master/stairs_model_bug.png[/img]

 

 

 

So please help me to find were is the problem !

How do I create my slope model to have a correct rendering ? (without using lightOpacity or TileEntitySpecialRender)

What did I do wrong ?

Or maybe it's a Minecraft or Forge bug ? (Edit : I think the second point can't be a Minecraft bug, because it does not appear on vanilla blocks. It does only appear on Forge registered blocks)

 

You can find the code of the slope (using ISmartBlockModel) and the code of the stairs (using the vanilla existing json model file) here : https://github.com/Zyfarok/Stairs-Test

 

If you want more images :

 

 

First point/bug :

 

 

Second point/bug :

 

Test with Opacity = 7 :

 

 

 

Thank for your help, and sorry for my bad English, I'm just a simple French student.

 

P.S.: All my screenshots are done in "brightness : Moody" (Minimum but default brightness settings)

[TheGreyGhost]

Hi

 

The direction-dependent lighting is based on face quads and the "shade" flag.  In the JSON it is called shade, in the FaceBakery  this is one of the flags, or alternatively in your BakedQuad it is one of the ints - see ModelBakery.makeBakedQuad -->  FaceBakery.storeVertexData

          "faces": {

                "down":  { "uv": [ 0, 0, 16, 16 ], "texture": "#bottom", "cullface": "down" },

                "up":    { "uv": [ 0, 0, 16, 16 ], "texture": "#top" },

vs the torch

            "shade": false,

            "faces": {

                "down": { "uv": [ 7, 13, 9, 15 ], "texture": "#torch" },

                "up":  { "uv": [ 7,  6, 9,  8 ], "texture": "#torch" }

            }

 

I think your second problem is related to your Block class definition, not the json, because the lighting is wrong for the adjacent block, not your block itself.  When I've seen these symptoms before it's generally been caused by  incorrect isOpaqueCube(), incorrect isFullCube() or incorrect block bounds

 

Just curious - why are you using ISmartBlockModel?  You can get the same sloped block using ordinary json?

 

-TGG

[Zyfarok]

Hi,

 

- For the First bug that you call "direction-dependent lighting", I use this to create my bakedQuad :

 

new BakedQuad(Ints.concat(vertexToInts(x1, y1, z1, color, texture, u1, v1),
                    vertexToInts(x2, y2, z2, color, texture, u2, v2),
                    vertexToInts(x3, y3, z3, color, texture, u3, v3),
                    vertexToInts(x4, y4, z4, color, texture, u4, v4)),
                    tintIndex, facing);

private int[] vertexToInts(float x, float y, float z, int color, TextureAtlasSprite texture, float u, float v)
    {
        return new int[] {
                Float.floatToRawIntBits(x),
                Float.floatToRawIntBits(y),
                Float.floatToRawIntBits(z),
                color,
                Float.floatToRawIntBits(texture.getInterpolatedU(u)),
                Float.floatToRawIntBits(texture.getInterpolatedV(v)),
                0
        };
    }

 

So I suppose that I need to change the "color" value to black and change the "tintIndex" for each different faces ? (Creating the shade manually)

EDIT : Ho maybe I should bring a fix tintIndex and generate the color as the FaceBakery.getFaceShadeColor(facing) does...

 

- For the second bug :

See the "StairsTestBlock" definition :

 

public class BlockStairsTest extends BlockStairs {
    private static final String NAME_START = "test";

    public BlockStairsTest(Block block) {
        this(block.getDefaultState(), blockName(block));
    }

    public BlockStairsTest(IBlockState modelState, String name) {
        super(modelState);
        setUnlocalizedName(name);
        this.setCreativeTab(CreativeTabs.tabBlock);
    }

    private static String blockName(Block block) {
        String blockName = block.getUnlocalizedName().substring(5);
        if (blockName.length() > 1)
            return NAME_START + blockName.substring(0,1).toUpperCase() + blockName.substring(1);
        else
            return NAME_START + blockName.toUpperCase();
    }
}

 

I didn't change any isOpaqueCube(), isFullCube() definitions ! And nether the block bounds...

 

Last thing, Why did I choose ISmartBlockModel ? Because :

- I wanted to create a generic block that I can register with different textures without creating tons of json files. And I was thinking that using ISmartBlockModel would help (but now I'm not sure)

- I don't know how to create triangles with the current json files. There is probably a way but I don't know how...

- I'm a noob

[TheGreyGhost]

Hi

 

yeah the tint index may also work I think.

 

But even better to just not use ISmartBlockModel.  Stick with the ordinary JSON method, it is much easier and also lets people modify your block textures much more easily!

 

Some information about JSON files and how you can make sloped quads

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

 

A triangle is just a quad with two adjacent corners on top of each other.

For example here

http://greyminecraftcoder.blogspot.co.at/2014/12/the-tessellator-and-worldrenderer-18.html

 

But perhaps even easier to use a program which can generate them for you (I think BDcraft Cubik can do this - never tried it with triangles I admit)

 

Curious that extending BlockStairs didn't work.  That should have been fine.

 

-TGG

 

[Zyfarok]

Thx for your help for the JSON, I think I will go back to this format.

 

For the triangles

A triangle is just a quad with two adjacent corners on top of each other.

Yes but how to do triangles in a json file ? I've seen a resource-pack json model using vertex but this resource-pack doesn't work anymore on 1.8 (it does before)

 

Curious that extending BlockStairs didn't work.  That should have been fine.

Yes and that's the real problem now !

 

EDIT :

If no-one find out from where the bug comes, it's maybe a Forge bug... So I tried to report the issue : https://github.com/MinecraftForge/MinecraftForge/issues/2019

And my problem for the triangles in json is still there ! (I will create a new post for that if the lighting bug is solved)

 

[TheGreyGhost]

Thx for your help for the JSON, I think I will go back to this format.

 

For the triangles

A triangle is just a quad with two adjacent corners on top of each other.

Yes but how to do triangles in a json file ? I've seen a resource-pack json model using vertex but this resource-pack doesn't work anymore on 1.8 (it does before)

Ah yeah, brain fade sorry.  I think you could also do this using the Blitz3D (B3DLoader) model loader for blocks that is now built into forge.  I don't reckon the vanilla model json can handle triangles (sloped quads yes, three-sided degenerate quads no).

 

Curious that extending BlockStairs didn't work.  That should have been fine.

Yes and that's the real problem now !

 

EDIT :

If no-one find out from where the bug comes, it's maybe a Forge bug... So I tried to report the issue : https://github.com/MinecraftForge/MinecraftForge/issues/2019

And my problem for the triangles in json is still there ! (I will create a new post for that if the lighting bug is solved)

Does the problem go away if you derive from a different type of block instead of BlockStairs? 

Do the dark sections stay there permanently or do they eventually pop to the correct value (a lighting update issue) after time, or if you place another block nearby?

You might also be able to narrow it down to an ambient occlusion / fancy lighting issue (a couple of those screenshots look like an ambient occlusion problem). 

I think this will be hard to track down; you would probably need to put a couple of breakpoints in the rendering code and see why the adjacent blocks are getting dud values for lighting calcs from your block.

 

-TGG

 

 

 

[Zyfarok]

I think you could also do this using the Blitz3D (B3DLoader) model loader for blocks that is now built into forge.

Okay... I will check this out... But If it's too complex it's maybe better to keep using some IBakedModel (Maybe an IModel wich return some IFlexibleBakedModel would be better than my ISmartBlockModel ?)

Does the problem go away if you derive from a different type of block instead of BlockStairs?

I will try with slabs... I will edit this when done.

Do the dark sections stay there permanently or do they eventually pop to the correct value (a lighting update issue) after time, or if you place another block nearby?

No it's permanent. When there is a block in front of the face, there is automatically the dark lighting.

You might also be able to narrow it down to an ambient occlusion / fancy lighting issue (a couple of those screenshots look like an ambient occlusion problem).

Yes I think that's an ambient occlusion / fancy lighting issue, but that's only for the registered block and this point is really weird...

I think this will be hard to track down; you would probably need to put a couple of breakpoints in the rendering code and see why the adjacent blocks are getting dud values for lighting calcs from your block.

If I need to I will try to track down... =/

 

[Zyfarok]

Problem solved !

 

In the Block.registerBlocks() method, I found this :

 

Iterator iterator = blockRegistry.iterator();
Block block13;
while (iterator.hasNext())
{
    block13 = (Block)iterator.next();
    if (block13.blockMaterial == Material.air)
    {
        block13.useNeighborBrightness = false;
    }
    else
    {
        boolean flag = false;
        boolean flag1 = block13 instanceof BlockStairs;
        boolean flag2 = block13 instanceof BlockSlab;
        boolean flag3 = block13 == block6;
        boolean flag4 = block13.translucent;
        boolean flag5 = block13.lightOpacity == 0;
        if (flag1 || flag2 || flag3 || flag4 || flag5)
        {
            flag = true;
        }
        block13.useNeighborBrightness = flag;
    }
}

 

 

My brain directly pop out that "useNeighborBrightness" should be true for my block, but this thing here is not applied to my block because my block is registered after the vanilla registration.

So I tried to do "useNeighborBrightness = true" in my block class (by chance, useNeighborBrightness is a protected field), and IT WORKS !

Look at this beautiful blocks <3 :

https://raw.githubusercontent.com/Zyfarok/Stairs-Test/master/bug_solved.png[/img]

I pushed "Stairs-Test" to allow you to see the simple "this.useNeighborBrightness = true;"

 

That's cool that there is a solution, but I think this is a bug and I will explain this in my issue to allow them to correct this. (if they also consider this as a bug)

Thanks for your help TGG, and also thanks for your "MinecraftByExample" tutorials =)

[TheGreyGhost]

Awesome dude, nice work

 

>        boolean flag1 = block13 instanceof BlockStairs;

>        boolean flag2 = block13 instanceof BlockSlab;

 

I should have guessed, freakin' Mojang and their dirty little quick fixes.

 

I think this is a good candidate for a Forge patch.

 

In your case, you could override getUseNeighbourBrightness() without having to access the protected field.

 

It's funny though, a couple of your symptoms don't seem to match that root cause, guess there's something more subtle going on that I'm not seeing.

 

-TGG

[Zyfarok]

I think this is a good candidate for a Forge patch.

It's not what LexManos is thinking >< https://github.com/MinecraftForge/MinecraftForge/issues/2019

In your case, you could override getUseNeighbourBrightness() without having to access the protected field.

Ha yes... I could also.

It's funny though, a couple of your symptoms don't seem to match that root cause, guess there's something more subtle going on that I'm not seeing.

Which symptoms ? It's seems really logical to me :

- Only appends on "forge registered" blocks => problem in registration...

- Black faces in the block itself -> The block face take the lighting of the block that this face is facing (Ex: north block for a north facing block), but if this face is obstructed, this takes the light of the block itself (0 in this case). But if you set "useNeighborBrightness = true" it takes the bigest light value from the six adjacent blocks.

- Black faces on others -> again, the block face take the lighting of the block that this face is facing. Here 0, but if you set "useNeighborBrightness = true", it's not 0 anymore.

 

P.S.: No matter, Now I'm having some fun with my block :